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