Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119797
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-238-g746678b8b6-fm-20230329.001-g746678b8
Mime-Version: 1.0
Message-ID: <ddb90963-7c1f-420c-903c-7d4070fe83d3@app.fastmail.com>
In-Reply-To: 
 <CAAwdEzDjaQUrL90VyXUHk4CpPu7UZ7ML24Z7=fu5_fkNocAR3A@mail.gmail.com>
References: 
 <CAJOtmejYbDktip6VK6HAVF97W4NJG4RUMX7GRc0gyi5BUpQWkA@mail.gmail.com>
 <080d1241-0956-41bf-aaf3-d9582cfce3ef@app.fastmail.com>
 <CAAwdEzDjaQUrL90VyXUHk4CpPu7UZ7ML24Z7=fu5_fkNocAR3A@mail.gmail.com>
Date: Thu, 30 Mar 2023 16:47:18 +0000
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Properties in interfaces
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, Mar 30, 2023, at 2:21 PM, Alexandru P=C4=83tr=C4=83nescu wrote:
> On Thu, Mar 30, 2023 at 3:50=E2=80=AFPM Larry Garfield <larry@garfield=
tech.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 avail=
able
>> here: https://wiki.php.net/rfc/property-hooks
>>
>>
> Do you think we could have a smaller RFC that only deals with properti=
es in
> interfaces that are just like what's allowed in classes right now, pub=
lic
> and public readonly?
> The need seems to be: a readonly property in classes and a interface t=
hat
> signals a get-only access so maybe readonly flag on interface attribut=
e is
> clear.

Not really.  For the hook-friendly version, we need to be able to separa=
te get and set requirements.  Hence:

interface I
{
  public string $foo { get; }
}

But separate get/set requirements is not a feature that exists today, si=
nce asymmetric visibility didn't pass.  So that would mean either includ=
ing syntax that does nothing but hopefully will in the future if somethi=
ng 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 asym=
metric visibility get added later. =20

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 shoul=
dn'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 wo=
uld be confusing if we DO add hooks or asymmetric visibility in the futu=
re, 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 l=
anguage causing problems is to do hooks and interface properties togethe=
r, so they can be complementary.  We considered doing interface properti=
es separately as a third RFC, but in practice they're most useful if the=
re are hooks available so decided to just combine them.

This is one of those cases where our lack of roadmap and planning capabi=
lity 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 ve=
rsion" first actually makes doing the full version harder, not easier.

--Larry Garfield