On Mon, Jul 22, 2024, at 7:07 PM, Tim Düsterhus wrote:
> 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)?
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
