> Le 11 déc. 2022 à 20:18, Larry Garfield <la...@garfieldtech.com> a écrit :
>
> 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
Hi,
As of today, the following declarations are rejected as syntax errors:
``php
class C {
$a;
int $b;
}
```
while the following declarations are accepted with implicit `public` visibility:
``php
class C {
static $c;
readonly int $d;
}
```
It would be reasonable to propose to allow to consistently omit the `public`
keyword. But allowing to omit it in some cases (including the most
controversial one: `protected(set)`) and not in other cases...? Because of this
inconsistency, people are incited to always write explicitly `public` anyway.
—Claude
