On Fri, Jul 26, 2024, at 13:36, Jordi Boggiano wrote:
> On 21.07.2024 11:21, Rob Landers wrote:
>>
>> On Sat, Jul 20, 2024, at 23:51, Larry Garfield wrote:
>>> On Sat, Jul 20, 2024, at 7:22 AM, Rodrigo Vieira wrote:
>>> > 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
>>>
>>
>> Just to play devil’s advocate, it was also before we had property hooks who
>> advertised itself as a way to “wrap and guard access to object properties”
>> but we are simply ignoring their existence here.
>>
> Just to compare them, because my initial gut feel was to say "yes please just
> put this together with hooks"..
>
> As far as I understand these would be the two options?
>
> class C {
> public protected(set) $answer { get => 42; set => { $this->answer =
> $value * 2; }
> public private(set) $publicReadOnly;
> }
>
>
> class C {
> public $answer { get => 42; protected set => { $this->answer =
> $value * 2; }
> public $publicReadOnly { private set; }
> }
>
> And now that I see it spelled out more, I do agree that while it appears a
> bit more verbose, and this "(set)" looks odd at first, having all the
> visibility upfront is a lot clearer than having to read through the hooks to
> see what visibility applies.
On a large property hook that potentially span hundreds of lines, I'd rather
only need to scroll up to the "set =>" to see how it is set vs. going all the
way back up to the property itself.
