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 <la...@garfieldtech.com>
> 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

Reply via email to