On Thu, Mar 30, 2023, at 2:21 PM, Alexandru Pătrănescu wrote:
> On Thu, Mar 30, 2023 at 3:50 PM Larry Garfield <[email protected]>
> wrote:
>
>>
>> This is a part of the "Property Hooks" RFC that Ilija and are working on.
>> It's not *quite* done yet, but it's mostly there. The draft is available
>> here: https://wiki.php.net/rfc/property-hooks
>>
>>
> Do you think we could have a smaller RFC that only deals with properties in
> interfaces that are just like what's allowed in classes right now, public
> and public readonly?
> The need seems to be: a readonly property in classes and a interface that
> signals a get-only access so maybe readonly flag on interface attribute is
> clear.
Not really. For the hook-friendly version, we need to be able to separate get
and set requirements. Hence:
interface I
{
public string $foo { get; }
}
But separate get/set requirements is not a feature that exists today, since
asymmetric visibility didn't pass. So that would mean either including syntax
that does nothing but hopefully will in the future if something else passes, OR
leaving that part out:
interface I
{
public string $foo;
}
which then wouldn't work (or at least not as well) if/when hooks or asymmetric
visibility get added later.
As for readonly, the more I've worked with it the more I think readonly is
fundamentally broken. Trying to use that as a "get only" syntax now would be
confusing, or restrict the property in ways the interface shouldn't. (Because
it would require the property to be readonly, which has all kinds of other
implications the class may not want.) And then it would be confusing if we DO
add hooks or asymmetric visibility in the future, which would need to use the
`{ get; set; }` syntax, but now you also have readonly in there, so how does
that interact?
The best answer that leaves the least confusing cruft lying around the language
causing problems is to do hooks and interface properties together, so they can
be complementary. We considered doing interface properties separately as a
third RFC, but in practice they're most useful if there are hooks available so
decided to just combine them.
This is one of those cases where our lack of roadmap and planning capability
really kneecaps PHP's ability to evolve cleanly. And we really don't want to
make the same mistake as readonly, where doing the "junior version" first
actually makes doing the full version harder, not easier.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
