> On 12 Dec 2022, at 02:18, Larry Garfield <la...@garfieldtech.com> wrote:
>
> On Thu, Dec 1, 2022, at 12:31 PM, Tim Düsterhus wrote:
>> Hi
>>
>> On 11/29/22 21:29, Larry Garfield wrote:
>>> Thank you everyone for the feedback. Based on this thread, we've made two
>>> changes to the RFC:
>>>
>>> 1. We've moved readonly back to forbidden with a-viz for now. I've added a
>>> section to Future Scope where we really should sort this out in the future,
>>> but we'll do that in the future when we can all focus on the various
>>> nuances of just that piece.
>>>
>>> 2. I rewrote the section on __set to make it clearer. That also included
>>> Ilija and I digging into all the nuances that are already present. The
>>> text may still look a bit complex, but that's because the existing logic is
>>> already complex with readonly. Long story short, the a-viz RFC does not
>>> change anything in the way __set works vis a vis asymmetric visibility; it
>>> just inherits and continues what readonly already started, so it's
>>> consistent.
>>>
>>> The PR should be updated in the next week or two with the latest changes.
>>> Baring any major need for change, we expect to call a vote for it shortly
>>> after New Years.
>>>
>>
>> Okay, then I'd like to officially "request" that the abbreviated form
>> [1] is dropped:
>>
>> I believe 'protected(set) string $foo' is easily confused with
>> 'protected string $foo' at a simple glance.
>>
>> Also any implicit rules are something developers will need to learn by
>> heart, whereas an explicit 'public protected(set) string $foo' could
>> reasonably be understood by someone without any PHP experience and some
>> basic experience of OO concepts.
>>
>> Having two separate explicit keywords also makes it much clearer that
>> asymmetric visibility is involved, because it's also asymmetric in the code.
>>
>> I believe the only benefit of the abbreviated form is saving 6
>> keystrokes (+ one hit to the spacebar) and I don't believe it's worth
>> the lack of clarity for an important property of the defined property.
>>
>> Best regards
>> Tim Düsterhus
>>
>> [1] https://wiki.php.net/rfc/asymmetric-visibility#abbreviated_form
>
>
> Does anyone else have feelings on this point? IMO, the shorthand makes a lot
> of sense when used with readonly to avoid lines getting just annoyingly long,
> but without it I can see the argument for not allowing it; it's about a wash
> in terms of length with readonly today. I'm comfortable going with the
> consensus on this one for now.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
I’ll just re-iterate what I said in chat a while ago - I think requiring the
dev to be explicit about making it public is a safer first step, and it has no
BC risk if you wanted to later allow the implicit variant, and without the
capability to combine with the readonly keyword (yet) it doesn’t seem like a
huge problem to be explicit IMO.
Cheers
Stephen
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
