On 5-8-2022 19:08, Larry Garfield wrote:
Ilija Tovilo and I are happy to present the first new RFC for PHP 8.3:
Asymmetric Visibility.
https://wiki.php.net/rfc/asymmetric-visibility
Details are in the RFC, but it's largely a copy of Swift's support for the same.
For what it's worth, here's my initial thoughts after reading the RFC:
1. In "Permitted visibility, it explicitly states that the "set" scope
MUST be more restrictive than the "get" scope. However, no reason for
this is provided. Please make the argumentation to support this choice
explicit.
2. In "Interaction with __set" and "Relationship with readonly" the RFC
states it wants to be consistent with the readonly behaviour, but that
is a different keyword. IMHO, these modifiers should work independently
of each other and are now improperly closely binded. If one wants
readonly behaviour, use the `readonly` keyword.
3. I only see a hat-tip to the property accessors RFC regarding the
chosen syntax.
I'd like to see a more extensive discussion and consideration of various
possible syntaxes.
Some potential alternatives:
- "visibility(get) visibility(set) type $prop" - which makes it explicit
what each visibility applies to
- "visibility(set: visibility) type $prop" - where it is clear that the
"main" visibility is the default and anything within the brackets a
deviation. This syntax would also more easily allow for expanding, like
"visibility(set: visibility, unset: visibility) type $prop"
I understand the desire for parallelism with Swift, but I don't think
that's a valid argument. The syntax should be right for PHP and if that
would happen to overlap/sync with a syntax used elsewhere: great, but
that's not an argument to only look at that syntax without a proper
discussion and due consideration for alternatives.
4. While I see no mention of "multi-property declarations", I presume
the visibility would apply to all ? I think it would be good to mention
this explicitly in the RFC as well.
* By "multi-property declarations", I mean: `public string $type,
$value = 'me', $somethingElse;
5. Are there tokenizer implications ? How will `set` (and possibly
`get`) be tokenized ?
6. As this is something which can already be handled via magic methods,
is there sufficient reason to make the language/engine more complicated
to support this via a syntax ?
Overall, I mainly just see an idea in the RFC, but no justification for
the need for it, let alone for any of the choices made.
Smile,
Juliette
