>>
>> 1. Relax the set-is-tighter restriction. That would allow `protected
>> protected(set)` etc. on any property. It wouldn't be particularly useful
>> unless readonly is being used, but it would be syntactically legal and
>> behave as you'd expect. We could still disallow "set is more permissive"
>> combinations (eg, `private public(set)`), as those have no apparent use case.
>
> I think that Option 1 is the most reasonable. The meaning of `public
> public(set)` and `protected protected(set)` is straightforward; from a user
> point-of-view, disallowing them seems more like “it is useless” than “it is
> confusing”. Unless there are good technical reason to restrict it, we can
> just leave to linting tools the care of reporting it.
>
> —Claude
>
To clarify my position:
* The set visibility must be either more restrictive or of the same restriction
level than the get visibility.
* When the set visibility is absent, it is inferred as following:
* If `readonly` is present, the set visibility is `private` (as of today);
* otherwise, the set visibility is the same as the get visibility (again,
as of today).
* We don’t judge whether it is reasonable to write `protected protected(set)
string $foo;` when you could just write `protected string $foo` for the same
effect. Similarly, we don’t judge whether it is reasonable to write `public
function()` when you could just write `function()` for the same effect. We
leave it to coding styles and linters to decide whether the short form or the
long form is preferred.
—Claude
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
