[RFC] Asymmetric Visibility, v2 View as Markdown

-----Original Message-----
From: Larry Garfield larry@garfieldtech.com
Sent: Wednesday, May 29, 2024 10:03 PM

Hello Larry,
just a quick thought.
Is there a reason why we cannot just make it "public private string
$x" instead of "public private(set) string $x"?
We would define that the second visibility specifier is for write.

The current proposal with "public private(set)" is less ambiguous, and
it is immediately obvious that this is something new, and not just
somebody accidentally added two modifiers.
At the same time, it feels a bit alien and cluttered.

Other options could be something like "public:private" or "public-
private".

A consequence of such options would be that you always need to specify
the read visibility along with the write visibility.
But this seems ok to me.

This is not a final opinion, just a thought.

We went through a bunch of syntax variations last year, including "public
private", "public:private", and "public private:set", plus a few others.
In an RCV poll, public private(set) was the favorite. (See link at the end
of the RFC.) It also allows for extension to other operations and scopes,
and for the short-hand syntax. Many of the other options did not support
those. Thus we stuck with the known syntax that had the most flexibility
and most support.

Would it make sense to do another RCV poll now that hooks are accepted, after lengthy discussion over its syntax?

Personally, I would prefer the HookEmbeddedStyle form. I don't think the argument that the visibility would potentially be separated from the hook definition is very strong, as you would have to scan for the existence of the hook anyway. For me, asymmetric visibility and property hooks are mentally more related than the RFC technically defines them to be.

Furthermore, I see a lot of reasoning in favour of the prefix syntax in relation to limitations of other language constructs like property promotion. While I don't think it is fair to expect this RFC should fix those, to me it feels we are compounding 'errors'.

Thanks to both you and Ilija for all the hard work on these RFC's, it is much appreciated!

--
Vincent de Lau

Le 30 mai 2024 à 17:07, Derick Rethans derick@php.net a écrit :

Now, if I define the property as public private(set) with similar
intentions, to make sure that there is no way for external scope or
extending classes scope to write to the property, while allowing
reading from external scope (or extending classes scope).

But the problem is that an extending class can define the property as
public protected(set), and that will easily allow the property that I
wanted to make sure it is private for writing to be changed by an
extending class to be protected.

public private(set) properties aren't really private, so you don't get
the shadowing, but you do have a point wrt to the expectation that an
inherited class can't easily override the private(set) part (with
protected(set) or public(set)).

Note that the issue already exists today with readonly properties: those are basically private(set); but if you redeclare a non-private readonly property in a subclass, you can in fact initialise it from the subclass bypassing the initial private(set) restriction of the superclass: https://3v4l.org/9AV4r

If you want a property not to be overridable, end of story, you can mark it as final (the final marker for properties was added as part of the hooks RFC, but it works also with non-hooked properties).

—Claude

Hi

If enough people felt strongly that it should be allowed, I don't think there's any technical reason it couldn't be allowed, other than it would allow some rather silly combinations. (Ilija can tell me if I'm wrong.) However, also note that it is, of course, much easier to allow more combinations in the future than to remove them, should we find they cause trouble.

One thing that would get pretty wonky would be private-read properties:
Private property names are currently internally "mangled" to include the
class name. This allows to define the same private property in multiple
classes of an inheritance chain, without those classes needing to know
about the private properties of each other and making the addition and
removal of a private property not a BC break. For all intents and
purposes those private properties to not exist, unless you are the class
itself.

I have no idea what the semantics of a public-write, private-read
property should be - and this problem is pretty similar to the
sibling-discussion about making private-set properties implicitly final,
because otherwise the semantics get wonky.

I believe that the case of making a property public-write, private-read
is best left to a virtual set-only hook.

Best regards
Tim Düsterhus

You guys are killing PHP. There is a lot of work to be done on the engine
to modernize it and make it more robust and sturdy. Shit like this just
adds more complexity to PHP in the name of convenience. I think this is my
cue to explore other languages for handling requests

On Mon, Jun 10, 2024 at 1:18 PM Rodrigo Vieira rodrigo.vieira92@outlook.com
wrote:

I didn't like the Prefix-style syntax. I prefer the
Hook-embedded-style syntax. First let's look at the counterpoints of the
Prefix-style syntax:

1) "Prefix-style is more visually scannable"

The set visibility is 10 lines away from the get visibility!

Solution:

class HookEmbeddedStyle
{
    public string $phone {
        private set {
            $this->phone = implode('', array_filter(fn($c) =>
is_numeric($c), explode($value)))
        }
        get {
            if (!$this->phone) {
                return '';
            }
            if ($this->phone[0] === 1) {
                return 'US ' . $this->phone;
            }
            return 'Intl +' . $this->phone;
        }
    }
}

The set visibility is not 10 lines away from the get visibility if you put
it at the top. For me this is about code convention, not about syntactic
structure:
only put the hook with explicit visibility at the top, when some of the
hooks do not have explicit visibility!

2) "Prefix-style is shorter"

public private(set) string $name;

public string $name { private set; }

Irrelevant to consider 1-2 characters.
If you break the lines needed for the hook block, the line (the horizontal
size) is smaller when using Hook-embedded-style and in my opinion it is
more readable because there is less information per line:

public private(set) string $name;

public string $name {
   private set;
}

3) "Prefix-style doesn't presume a connection with hooks"

As noted above in "Interaction with hooks", visibility controls exist
independently of hooks.

I agree, but with Property Hooks, this should now define the overall
visibility only. Like a bigger gate that you open, and there are other
doors defining the visibility of the operations get, set (hooks).

In fact, as implemented, they don't interact at all. Using hook syntax
for visibility controls is therefore surprising and confusing.

Why "surprising and confusing"? I see hooks as a different kind of
function/method.
Property Hooks RFC shouldn't pass without requiring hook parentheses, for
any hook when the property is not abstract. The $value in the set hook
seems to come out of nowhere to some people (the exception is for hooks
declared on an abstract property which you can define without parameters
and thus you are free to define whatever parameters you want on the
concrete property).

When you define a method in PHP, it should be possible to omit the
"function", but the parameters should be required because that's the nature
of a function/method: to have parameters.

4) "It's non-obvious in Hook-embedded-style what hook behavior should

be implied"

...So “arrays with hooks can do less” is already an established fact of
the language. However, if the hook-style syntax is used for visibility:

class A
{
    public array $arr { protected set; }
}

class B extends A
{
    public function add(int $val)
    {
        // Should this be legal?
        $this->arr[] = $val;
    }
}

$b = new B();

$b->add(5);

First of all: non-abstract property hook must have a body.
Second: when asymmetric visibility is explicit, it means that symmetric
visibility is implicit: a declared hook that does not have declared
visibility has the same general visibility as the property, in this case:
public.

Third:
There's another limitation on hooks here that makes things a bit
confusing: there's a missing hook for a specific operation because you can
clearly separate the set from the push operation...

Solution:

abstract class A
{
    abstract public array $arr {
        push; // Hook available only for "array" type properties only;
public visibility
        private set;
    }
}

class B extends A
{
    public array $arr {
        push ($value) { // `public push ...` here is redundant
            // Mandatory to implement logic here.
        }
        private set ($value) {
            // Mandatory to Implement logic here.
        }
    }

    public function __construct ()
    {
        // Legal ✅ (set hook is protected)
        $this->arr = [1]; // call set hook
    }
    public function add(int $value)
    {
        // Legal ✅ (push hook is public)
        $this->arr[] = $value; // call push hook
    }
}

$b = new B();

$b->add(5);
$b->arr; // Legal ✅ (Inherited from the general visibility that is public)
$b->arr = [1, 2, 3]; // Fatal error ❌ - access to set hook is private only
$b->arr[] = 4; // Legal ✅ - call public push hook

My point: Prefix-style is not future-proof

1) The Prefix-style is not compatible with new hooks

If more hooks are added in the future, such as the push hook for arrays
or even a hook that is compatible with all types such as init,
Hook-embedded-style will become compatible, but Prefix-style not.

2) Hook overloading

If hook overloading is added in the future, Prefix-style would not be
supported to have this granular visibility into operations. For example, it
might be possible to add a public hook and a protected hook for the same
operation, where one would be triggered if the operation occurred from
outside the class, and the other if the operation occurred from inside the
class.
Em 10 de jun. de 2024 13:15 -0300, Tiffany tiffany.k.taylor@gmail.com
escreveu:

On Wed, May 29, 2024, 2:16 PM Larry Garfield larry@garfieldtech.com
wrote:

As promised, Ilija and I offer this revised version of asymmetric
visibility.

https://wiki.php.net/rfc/asymmetric-visibility-v2

It's still essentially the same as last year's version, but with a few
adjustments and changes:

• readonly properties are now supported in a logical fashion.
• We've brought back the abbreviated form, as public-read, something else
  set is the most common use case.
• The section on magic methods has been greatly simplified. The
  implementation itself hasn't changed, but the explanation is a lot less
  confusing now.
• We've explained how aviz interacts with hooks (they don't, really) and
  with interface properties (in the obvious way), which didn't exist at the
  time of the last draft.
• We've added a section with examples of how aviz is a concrete
  improvement, even in a world with readonly and hooks.
• We've added a section discussing why the prefix-style syntax was chosen.

dons flame retardant suit

--
Larry Garfield
larry@garfieldtech.com

Sending an email to quickly enable a new mailing list subscriber to engage
in the conversation.

I didn't like the Prefix-style syntax. I prefer the Hook-embedded-style syntax. First let's look at the counterpoints of the Prefix-style syntax:

1) "Prefix-style is more visually scannable"

The set visibility is 10 lines away from the get visibility!

Solution:

class HookEmbeddedStyle
{
    public string $phone {
        private set {
            $this->phone = implode('', array_filter(fn($c) => is_numeric($c), explode($value)))
        }
        get {
            if (!$this->phone) {
                return '';
            }
            if ($this->phone[0] === 1) {
                return 'US ' . $this->phone;
            }
            return 'Intl +' . $this->phone;
        }
    }
}

The set visibility is not 10 lines away from the get visibility if you put it at the top. For me this is about code convention, not about syntactic structure:
only put the hook with explicit visibility at the top, when some of the hooks do not have explicit visibility!

2) "Prefix-style is shorter"

public private(set) string $name;

public string $name { private set; }

Irrelevant to consider 1-2 characters.
If you break the lines needed for the hook block, the line (the horizontal size) is smaller when using Hook-embedded-style and in my opinion it is more readable because there is less information per line:

public private(set) string $name;

public string $name {
   private set;
}

3) "Prefix-style doesn't presume a connection with hooks"

As noted above in "Interaction with hooks", visibility controls exist independently of hooks.

I agree, but with Property Hooks, this should now define the overall visibility only. Like a bigger gate that you open, and there are other doors defining the visibility of the operations get, set (hooks).

In fact, as implemented, they don't interact at all. Using hook syntax for visibility controls is therefore surprising and confusing.

Why "surprising and confusing"? I see hooks as a different kind of function/method.
Property Hooks RFC shouldn't pass without requiring hook parentheses, for any hook when the property is not abstract. The $value in the set hook seems to come out of nowhere to some people (the exception is for hooks declared on an abstract property which you can define without parameters and thus you are free to define whatever parameters you want on the concrete property).

When you define a method in PHP, it should be possible to omit the "function", but the parameters should be required because that's the nature of a function/method: to have parameters.

4) "It's non-obvious in Hook-embedded-style what hook behavior should be implied"

...So “arrays with hooks can do less” is already an established fact of the language. However, if the hook-style syntax is used for visibility:

class A
{
    public array $arr { protected set; }
}
 
class B extends A
{
    public function add(int $val)
    {
        // Should this be legal?
        $this->arr[] = $val;
    }
}
 
$b = new B();
 
$b->add(5);

First of all: non-abstract property hook must have a body.
Second: when asymmetric visibility is explicit, it means that symmetric visibility is implicit: a declared hook that does not have declared visibility has the same general visibility as the property, in this case: public.

Third:
There's another limitation on hooks here that makes things a bit confusing: there's a missing hook for a specific operation because you can clearly separate the set from the push operation...

Solution:

abstract class A
{
    abstract public array $arr {
        push; // Hook available only for "array" type properties only; public visibility
        private set;
    }
}

class B extends A
{
    public array $arr {
        push ($value) { // `public push ...` here is redundant
            // Mandatory to implement logic here.
        }
        private set ($value) {
            // Mandatory to Implement logic here.
        }
    }

    public function __construct ()
    {
        // Legal ✅ (set hook is protected)
        $this->arr = [1]; // call set hook
    }
    public function add(int $value)
    {
        // Legal ✅ (push hook is public)
        $this->arr[] = $value; // call push hook
    }
}

$b = new B();

$b->add(5);
$b->arr; // Legal ✅ (Inherited from the general visibility that is public) 
$b->arr = [1, 2, 3]; // Fatal error ❌ - access to set hook is private only
$b->arr[] = 4; // Legal ✅ - call public push hook

My point: Prefix-style is not future-proof

1) The Prefix-style is not compatible with new hooks

If more hooks are added in the future, such as the push hook for arrays or even a hook that is compatible with all types such as init, Hook-embedded-style will become compatible, but Prefix-style not.

2) Hook overloading

If hook overloading is added in the future, Prefix-style would not be supported to have this granular visibility into operations. For example, it might be possible to add a public hook and a protected hook for the same operation, where one would be triggered if the operation occurred from outside the class, and the other if the operation occurred from inside the class.
Em 10 de jun. de 2024 13:15 -0300, Tiffany tiffany.k.taylor@gmail.com escreveu:

As promised, Ilija and I offer this revised version of asymmetric visibility.

https://wiki.php.net/rfc/asymmetric-visibility-v2

It's still essentially the same as last year's version, but with a few adjustments and changes:

• readonly properties are now supported in a logical fashion.
• We've brought back the abbreviated form, as public-read, something else set is the most common use case.
• The section on magic methods has been greatly simplified. The implementation itself hasn't changed, but the explanation is a lot less confusing now.
• We've explained how aviz interacts with hooks (they don't, really) and with interface properties (in the obvious way), which didn't exist at the time of the last draft.
• We've added a section with examples of how aviz is a concrete improvement, even in a world with readonly and hooks.
• We've added a section discussing why the prefix-style syntax was chosen.

dons flame retardant suit

--
Larry Garfield
larry@garfieldtech.com

Sending an email to quickly enable a new mailing list subscriber to engage in the conversation.

I’m also not a fan of the prefix style, but for different reasons. My main reason is that it increases the minimum line-length, potentially forcing you to chop things down into awkward looking lines:

public
private(set)
string $longvarname {
get;
set;
}

I find that extremely hard to scan, but maybe others do not. The more natural looking syntax is easier to scan and reason about (IMHO):

public
string $longvarname {
get;
private set;
}

If I’m having to read the code, I prefer to have everything near where it is used so I don’t have to scroll up to the top and see its visibility. Granted, I haven’t used property hooks and I have no idea how IDEs will help here; maybe it is a non-issue — but I guess people still have to do code reviews which very rarely comes with IDE powers.

— Rob

Will the alternative syntax on hook not even be put to a vote?

It was, a year and a half ago when Aviz was first proposed. The preference was split, but leaned toward the prefix-style syntax. So we went with that. I don't think we'll ever get everyone to want the same syntax, but we're using the one that was both somewhat more popular, and (as discussed in the RFC) arguably superior.

As the "comments in yield from" thread has shown, any even slight change to PHP's syntax will require work from static analysis tools. That's the nature of the problem space, regardless of the syntax specifics.

--Larry Garfield

Hi Rob

https://wiki.php.net/rfc/asymmetric-visibility-v2

Hi folks. After a side quest to polish off hooks, we're nearly ready to bring aviz to a vote.

We've made one change since we last discussed it: Specifically, Ilija realized that __set's behavior is already inconsistent, so supporting it for aviz properties with invisible set would make it even more inconsistent, not less. For that reason, we've changed the __set behavior such that a non-readonly aviz property will not trigger __set. Further details are in the RFC, but in short, all of the use cases for that behavior now have better alternatives, such as property types, hooks, and aviz itself. So there's really no point to falling back to __set in edge cases.

https://wiki.php.net/rfc/asymmetric-visibility-v2#interaction_with_set_and_unset

Hmm,

There’s a lot of existing code that relies on this behavior, it’s pretty much the best way to create proxies without requiring code generation.

This is a pretty massive breaking change.

There was a miscommunication between Larry and me. The change is not
to any existing behavior. __get/__set are currently called under two
circumstances:

• The properties full visibility is not met.
• The property was explicitly unset.

We're not changing this behavior. Instead, we decided not calling
__set for asymmetric visibility, when only the set visibility isn't
met. Before making this decision, implicitly implying protected(set)
for a readonly property would have led to __set being called (because
the scope protection now comes from asymmetric visibility, rather than
readonly itself), which would have been a change to the current
behavior.

So, in short: If only the set visibility isn't met, we're now throwing
an error. This is consistent with readonly today, and with get-only
hooks. If somebody wants to change this in the future, they can do so
without any BC breaks, and most likely should make the behavior
consistent across all of these three cases.

Ilija

Hi

We've made one change since we last discussed it: Specifically, Ilija realized that __set's behavior is already inconsistent, so supporting it for aviz properties with invisible set would make it even more inconsistent, not less. For that reason, we've changed the __set behavior such that a non-readonly aviz property will not trigger __set. Further details are in the RFC, but in short, all of the use cases for that behavior now have better alternatives, such as property types, hooks, and aviz itself. So there's really no point to falling back to __set in edge cases.

https://wiki.php.net/rfc/asymmetric-visibility-v2#interaction_with_set_and_unset

Baring any new developments, we plan to start the vote early next week.

I find it unfortunate that this RFC received a non-trivial change on a
Saturday after the discussion has been idle for more than a month
together with the announcement that the vote will begin shortly after
the weekend. Folks should be given sufficient time to react to the
newest developments. Personally I plan to give this RFC another read,
because I already forgot the details after a month of not looking at it,
but I'm not sure if I'll manage today.

For now:

Is there any implementation of this RFC? The RFC text only references
the https://github.com/php/php-src/pull/9257 PR hasn't been updated
since December 2022.

Best regards
Tim Düsterhus

Oof, sorry, I thought Ilija had updated the link already. It is now updated, and the PR is here:

https://github.com/php/php-src/pull/15063

Since the PR wasn't easily available until now, we're going to push the vote start back to this coming Friday.

--Larry Garfield

Hi

Baring any new developments, we plan to start the vote early next week.

I've went through the RFC once more. I have the following remarks:

For that reason, a private(set) property is automatically final and may not be redeclared at all.

I assume that explicitly marking it as final is still allowed (just
redundant)?

Correct. I have added a comment to that effect.

There is one caveat regarding virtual properties that have no set operation. If there is no set operation defined on a property, then it is nonsensical to specify a visibility for it. That case will trigger a compile error. For example:

How does this interact with inheritance? Consider the following example:

 class P {
     public $answer { get => 42; }
 }

 class C extends P {
     public protected(set) $answer { get => 42; set => 'dummy'; }
 }

This could be considered to be both narrowing the set visibility from
public to protected (which is unsound), but also widening it from
“never” to protected (which would be sound).

I checked with Ilija, and confirmed that it's the second. I have updated the RFC accordingly to make that explicit.

as it's possible now for a property to be visible but not writeable. For the time being,

I dislike the “for the time being” phrasing, because changing that would
effectively result in a breaking change, because the __set() may be
called in situations that were not anticipated. I would have preferred a
stronger phrasing that makes it clear that the RFC authors know what
they are talking about.

Best regards
Tim Düsterhus

I wordsmithed this a bit further. We're not trying to be wishy-washy. Rather, there are a couple of knock-on implications that are worth discussing that we consider off topic, but the approach we're taking does not preclude them. We're deliberately taking the conservative approach. Adding a __set fallback in the future would not be a BC break, as it would be changing a hard error condition to a legal condition, which is something nearly all new features do. We don't think it's wise to do that, but if someone wanted to advocate for that in the future we're not precluding it. If none of those further discussions happen, we still consider this behavior complete and acceptable.

--Larry Garfield