Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108725
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
In-Reply-To: <4d9688fe-cc57-44af-903e-05f4cbb1bbcc@www.fastmail.com>
Date: Sun, 23 Feb 2020 03:39:33 -0500
Cc: php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <452D962A-C588-4F04-B000-479EBEA9B9DB@newclarity.net>
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>
 <4d9688fe-cc57-44af-903e-05f4cbb1bbcc@www.fastmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Immutable/final/readonly properties
From: mike@newclarity.net (Mike Schinkel)

> On Feb 21, 2020, at 6:17 PM, Larry Garfield <larry@garfieldtech.com> =
wrote:
> I'm totally on board for better value object support, so that's a good =
motive for me.  The question I have is whether this is really a good =
stepping stone in that direction or if it would lead down a wrong path =
and lock 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 lead into properly immutable value objects?  Or do they give =
us that themselves?
>=20
> The biggest challenge for immutable objects, IMO, is evolving them.  =
Eg, $result->withContentType(...) to use the PSR-7 example.  Would we =
expect 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 =
syntactic way to modify them directly?
>=20
> The with*() method style requires cloning the object.  What happens to =
the locked status of a set property if the object is cloned?  Are they =
then settable again, or do they come pre-locked?
>=20
> 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 =
the 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 it changed, once, which creates a loophole.  I'm not sure what the =
right answer is here.
>=20
> My other concern is a public property (the most likely use case) would =
have 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 class tries to set it lazily, it may already have been set by some =
external code (rightly or wrongly) and cause a failure.

>=20
> How do we address that?  There's absolutely use cases where setting =
everything in the constructor ahead of time is what you'd do anyway, but =
there are plenty where you wouldn't want to, either, which creates a =
race condition for who sets it first, or tries to access it before it =
gets set, etc.  (This is where my repeated questions about lazy =
initialization come from.)


I have struggled to follow this RFC thread fully, so if I am getting =
something out of context, please note that and I apologize in advance.

However, it would see that rules for `write once` properties to support =
lazy loading would be rather simple:

1. Write-once properties can only be updated once.
2. Write-once properties can only be updated within the class where they =
are declared.
3. If you want to update a property from outside the class, create a =
set_<property>() method to allow it to happen.
4. If you do not want it to be set externally, do not implement a =
set_<property>() method.
5. If you want it to be implemented externally sometimes but not others, =
implement guard classes inside the set_<property>() method.

I think that addresses all scenarios, no?

-Mike=