Hi
On 7/20/24 03:14, Larry Garfield wrote:
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)?
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).
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
