Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112703
User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396
Mime-Version: 1.0
Message-ID: <c9949f2e-79a7-4a35-9d0e-c8a8ba861fb0@www.fastmail.com>
In-Reply-To: 
 <CAJpLVh3c2o+RDjEg+GenLJa9rh5iLXMu8VZnbkdM0_n0FmfM=A@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>
Date: Fri, 01 Jan 2021 13:14:42 -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 Thu, Dec 31, 2020, at 8:04 AM, Olle H=C3=A4rstedt wrote:
> 2020-12-31 12:37 GMT, Rowan Tommins <rowan.collins@gmail.com>:

> > On 30/12/2020 18:42, Olle H=C3=A4rstedt wrote:
> >>> To put it a different way, value types naturally form*expressions*=
,
> >>> which mutable objects model clumsily. It would be very tedious if =
we had
> >>> to avoid accidentally mutating the speed of light:
> >>>
> >>> $e =3D (clone $m) * ((clone $c) ** 2);
> >> Using a variable on right-hand side does not automatically create a=
n
> >> alias, so in the above case you don't have to use clone.
> >
> >
> > Whether or not the type system forced you to, you'd have to use clon=
e if
> > the values were implemented as mutable. Switching to methods again m=
ay
> > make that clearer:
> >
> > $c =3D new MyNumber(299_792_458);
> > $m =3D new MyNumber(10);
> > $e =3D $m->multiply( $c->square() );
> >
> > If multiply() and square() are mutating state, rather than returning=
 new
> > instances, $c is now 89875517873681764, which is going to totally me=
ss
> > up the universe...
> >
> >
> > Regards,
> >
> > --
> > Rowan Tommins
> > [IMSoP]
>=20
> Yes, of course you can find use-cases where immutability is a better
> choice, just like I can find use-cases where (constrained) mutability
> is better. The point is not to replace one tool with another, but
> rather adding another tool to the toolbox. The web dev discourse is
> one-sided with regard to immutability, I think. Wish I had time to
> implement a PR to Psalm to show something more concrete... Again, if
> you only have a hammer, everything looks like a nail. :)
>=20
> Olle

> The web dev discourse is
> one-sided with regard to immutability,=20

Yes, if you've heard any of the regular whining about PSR-7 being an imm=
utable 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 immutabili=
ty in PHP in syntactically clumsy and ugly.  We want to fix that, and th=
at has to include some means of "give me a new value based on this exist=
ing value but with some difference."  (aka, exactly what with-er methods=
 do, although I agree entirely that if you have the option of less gener=
ic names, use them).

So, can we get back to the original post, which is proposing specifics o=
f the tools to make that happen? :-)  (Asymmetric visibility and clone-w=
ith, specifically.)

--Larry Garfield