Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108716
User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1
Mime-Version: 1.0
Message-ID: <4d9688fe-cc57-44af-903e-05f4cbb1bbcc@www.fastmail.com>
In-Reply-To: 
 <CAH5C8xWgkUCAJguwnP69VqWXUaR+QtJRPMyBdv7B5vcnQjTD1g@mail.gmail.com>
References: 
 <CAH5C8xVYFkgyW88332ei8coMOijuynHXg3A2dL50XU4HP5Vpyw@mail.gmail.com>
 <CAKuGYLTsK2h_Yeo1vMju867hhmzyHt+GwoGStcQtiYMi2VB1tg@mail.gmail.com>
 <CAF+90c9RKf5PUQY0XHf=8QVVMw8jiJ=7eWfY5TTANEYt-a-ZAA@mail.gmail.com>
 <8545d15e-ddd5-42be-8405-09697a077234@www.fastmail.com>
 <CAH5C8xWgkUCAJguwnP69VqWXUaR+QtJRPMyBdv7B5vcnQjTD1g@mail.gmail.com>
Date: Fri, 21 Feb 2020 17:17:30 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Immutable/final/readonly properties
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Feb 21, 2020, at 4:29 AM, M=C3=A1t=C3=A9 Kocsis wrote:
> >
> > Yeah, I'm definitely thinking in relation to the earlier discussion,=
 since
> > I think they're all inter-related.  (This, property accessors, and c=
onstant
> > expressions.)
> >
>=20
> The biggest question is whether it's worth to support both readonly
> properties and property accessors. My answer is clear yes, because the=
re
> are many-many
> ways to mess with private or protected properties without and public
> setters from the outside - in which case property accessors couldn't h=
elp
> much. I collected some examples I know of:
> https://3v4l.org/Ta4PM

I didn't even know you could do some of those.  That's horrifying. :-)

> > As Nikita notes above, a read-only property with a default value is.=
..
> > basically a constant already.  So that's not really useful.
>=20
> I agree that they are not very useful, however I wouldn't restrict the=
ir
> usage. Mainly because there are probably some legitimate use-cases, bu=
t I
> also think it would
> be advantageous to be consistent with the other languages in this case=
.

If they could do something that class constants can't, that would make t=
hem useful.  If not, then I feel like it would just be introducing new s=
yntax for the same thing, without much benefit.  (I'm thinking of, eg, c=
ould you set them by default to a new Foo() object, which you could then=
 modify the Foo but not change it for another object, thus moving that i=
nitialization out of the constructor?  That sort of thing.)

> > If we could address the performance impact, that would give us much =
more
> > functionality-for-the-buck, including an equivalent of read-only pro=
perties
> > including potentially lazy initialization.  Or derive-on-demand beha=
vior
> > would also be a big increase in functionality.
> >
> > It's not that I don't see a value to this RFC; I actually have a few=

> > places in my own code where I could use it.  It's that I see it as b=
eing of
> > fairly narrow use, so I'm trying to figure out how to increase it so=
 that
> > the net-win is worth it.
> >
>=20
> The reason why I brought up this RFC is that I'd really like to add
> first-class support for immutable objects, and it seemed to be a good =
idea
> to first go for readonly properties.
> This way, the scope of an immutable object RFC gets smaller, while it'=
s
> possible to only have readonly properties alone.
>=20
> Regards,
> M=C3=A1t=C3=A9

I'm totally on board for better value object support, so that's a good m=
otive for me.  The question I have is whether this is really a good step=
ping stone in that direction or if it would lead down a wrong path and l=
ock us into too much TIMTOWTDI (for the Perl fans in the room).  So let'=
s think that through down that path.  How would write-once properties le=
ad into properly immutable value objects?  Or do they give us that thems=
elves?

The biggest challenge for immutable objects, IMO, is evolving them.  Eg,=
 $result->withContentType(...) to use the PSR-7 example.  Would we expec=
t people to do it with a method like that, or would there be some other =
mechanism?  If the properties are public, would we offer a more syntacti=
c way to modify them directly?

The with*() method style requires cloning the object.  What happens to t=
he locked status of a set property if the object is cloned?  Are they th=
en settable again, or do they come pre-locked?

Neither of those seem good, now that I think about it.  If they come pre=
-locked, then you really can't clone, change one property, and return th=
e new one (as is the standard practice now in that case).  If they don't=
 come pre-locked, then the newly created object can have everything on i=
t changed, once, which creates a loophole.  I'm not sure what the right =
answer is here.

My other concern is a public property (the most likely use case) would h=
ave to be set in the constructor.  If it's not, then callers cannot rely=
 on it having been set yet if it's set lazily.  And if code inside the c=
lass tries to set it lazily, it may already have been set by some extern=
al code (rightly or wrongly) and cause a failure.

How do we address that?  There's absolutely use cases where setting ever=
ything in the constructor ahead of time is what you'd do anyway, but the=
re are plenty where you wouldn't want to, either, which creates a race c=
ondition for who sets it first, or tries to access it before it gets set=
, etc.  (This is where my repeated questions about lazy initialization c=
ome from.)

--Larry Garfield