Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112711
User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396
Mime-Version: 1.0
Message-ID: <34d6a045-f7c3-4a77-8b22-378e84b2d1f9@www.fastmail.com>
In-Reply-To: 
 <CAJpLVh3NaqgHJgf0q61tX-fjL1uCMaLcR-1JcdP=0Cx00h1FHQ@mail.gmail.com>
References: <1d0abb04-4987-43a9-85bc-bccc3bd6be9a@www.fastmail.com>
 <03108284-740a-4a5d-130f-15b2e67e9df9@mabe.berlin>
 <CAJpLVh2M3iKhG8b2qZydf_70K4NYdZ5fpSEsRNK7uLeESUPHKg@mail.gmail.com>
 <459d7ff7-e553-dce9-7d43-c3b1e772e572@gmail.com>
 <CAJpLVh31UzSJvKdypQ=Mh+6CLvfUCrF==z6HBDD1_nuYqFzG5A@mail.gmail.com>
 <7f4fe9ca-1c20-6f69-cef0-a9718af742a3@gmail.com>
 <C9E7D7C8-2EB8-479A-B0BF-E992172765EE@newclarity.net>
 <30906866-1971-8395-05a0-fd78d054bb89@gmail.com>
 <CAJpLVh3c2o+RDjEg+GenLJa9rh5iLXMu8VZnbkdM0_n0FmfM=A@mail.gmail.com>
 <c9949f2e-79a7-4a35-9d0e-c8a8ba861fb0@www.fastmail.com>
 <CAJpLVh3NaqgHJgf0q61tX-fjL1uCMaLcR-1JcdP=0Cx00h1FHQ@mail.gmail.com>
Date: Sat, 02 Jan 2021 10:06:36 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: =?UTF-8?Q?Re:_[PHP-DEV]_Analysis_of_property_visibility,_immutability,_a?=
 =?UTF-8?Q?nd_cloning_proposals?=
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Jan 1, 2021, at 5:51 PM, Olle H=C3=A4rstedt wrote:

> >> The web dev discourse is
> >> one-sided with regard to immutability,
> >
> > Yes, if you've heard any of the regular whining about PSR-7 being an=

> > immutable object you'd think it's one-sided in favor of mutability. =
;-)
> >
> > As you say, the point here is to add tools.  Right now, doing immuta=
bility
> > in PHP in syntactically clumsy and ugly.  We want to fix that, and t=
hat has
> > to include some means of "give me a new value based on this existing=
 value
> > but with some difference."  (aka, exactly what with-er methods do, a=
lthough
> > I agree entirely that if you have the option of less generic names, =
use
> > them).
> >
> > So, can we get back to the original post, which is proposing specifi=
cs of
> > the tools to make that happen? :-)  (Asymmetric visibility and clone=
-with,
> > specifically.)
> >
>=20
> OK!
>=20
> I like that you connect higher level design patterns with language
> design. This is the way to go, IMO. Personally, I'd prefer support for=

> the Psalm notation `@psalm-readonly`, which is the same as your
> initonly. Clone-with makes sense too, as this construct is already
> supported in multiple languages. The exact notation doesn't matter
> that much - my personal choice is OCaml {record with x =3D 10} over JS=

> spread operator, but OCaml is pretty "wordy" in notation in contrast
> to the C tradition that PHP is part of.
>=20
> Reintroducing "objects that pass by value" is a hard pass from me. The=

> way forward is immutability and constrained mutability (ownership,
> escape analysis, etc). Psalm also supports array shapes - maybe this
> can be investigated as an alternative? Since PHP has no tuples.
>=20
> I'm not convinced the added complexity of asymmetric visibility is
> powerful enough to motivate its existence. Feel free to prove me
> wrong. :) My choice here would be namespace "internal" (also supported=

> by Psalm already), but this requires implementation of namespace
> visibility, a PR that was abandoned.
>=20
> And also, happy new year!

Happy New Year!

I agree that "objects, but passing by value" would not be the right solu=
tion. I used to think that would be a good part of the solution, but eve=
ntually concluded that it would introduce more complexity, not less.  Ev=
entually, everything people wanted to do with objects they'd want to do =
with "Records" (for lack of a better term), and if they pass by value bu=
t are still mutable then you have a weird situation where sometimes chan=
ges propagate and some don't (depending on if you have a record or objec=
t).  Making it easier to use objects in a value-esque way will get us cl=
oser to the desired end state.

I think the tldr of my post is this: A single "immutable" flag (whatever=
 it's called) on a class or property would require having lots of holes =
poked in it in order to make it useful in practice (mostly what "initonl=
y" would do), but those holes would introduce other holes we don't want =
(cloning an object from the outside when you shouldn't).

Asymmetric visibility, however, doesn't give us true immutability but al=
lows a class author to more easily emulate it "close enough", while also=
 supporting various other use cases.  Its gap is the class author, not t=
he entire rest of the programming industry.  That makes it much safer, a=
nd gets us to objects that are effectively immutable from the outside, w=
hich is what's important.  (If they're mutable from the inside, either t=
here are use cases for that or rely on the good behavior of just the cla=
ss author, who is in the best position to know if the object should be i=
nternally immutable or not.)

Pairing that with an easy clone-with-change syntax would allow class aut=
hors to easily construct something that is immutable-in-practice fairly =
easily, even if it's not Twue Immutability(tm).

--Larry Garfield