Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112824
User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396
Mime-Version: 1.0
Message-ID: <dd090882-64f8-4ad7-8713-229dc5008cef@www.fastmail.com>
In-Reply-To: 
 <CAJpLVh03V=zFrqnOQEtHegbqGyvC9qWrGcHocVnpE3P=3sHu1Q@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>
 <34d6a045-f7c3-4a77-8b22-378e84b2d1f9@www.fastmail.com>
 <CAJpLVh3beDDUieJTnBDJdJHnOZezggWgBfz6eYAQJVF4_jotPw@mail.gmail.com>
 <12c6939d-14ed-4f7c-b2bc-189307a20f74@www.fastmail.com>
 <CAJpLVh03V=zFrqnOQEtHegbqGyvC9qWrGcHocVnpE3P=3sHu1Q@mail.gmail.com>
Date: Sat, 09 Jan 2021 18:33:10 -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 Sun, Jan 3, 2021, at 11:29 AM, Olle H=C3=A4rstedt wrote:

> > I'll disagree slightly.  A language feature should introduce more po=
wer than
> > it does complexity.  Not everything *can* be made absolutely simple,=
 but the
> > power it offers is worth it.  I'd say it should minimize introduced
> > complexity, relative to the power offered.  Complexity ideally is su=
per low,
> > but it's never zero simply by virtue of being "one more thing" that
> > developers need to know how to read.
> >
> > So in this case, we need to compare the power/complexity of asymmetr=
ic
> > visibility vs the power/complexity of "immutable... except in these
> > situations."  I would argue that asymmetric visibility is more
> > self-documenting, because it states explicitly what those situations=
 are.
> >
> > The other point is that, as noted, "initonly" creates a gap if you h=
ave
> > properties that are inter-dependent.  Those then cannot be made publ=
ic-read,
> > because that would also mean public-clone-with, and thus allow calle=
rs to
> > violate property relationships.  Asymmetric visibility does not have=
 that
> > problem.
>=20
> Can you perhaps be a bit more clear on why initonly/readonly would be
> a deal breaker? Seems to me like readonly would cover 80% of
> use-cases? Which is to make data-value objects humane (and fast, since=

> you don't need getters anymore) to work with. Seems like you're
> focusing too much on an edge case here. Maybe we should list the
> possibly use-cases? Or at least the main target use-case.
>=20
> If an object has invariants that need to hold, just throw an exception=

> in __clone to force use with withX() instead? Or, as you suggested,
> improve __clone by giving it arguments?
>=20
> Olle

It took a few days, but I am back with some more concrete examples.  I d=
ecided to try and convert PSR-7 to the various options considered in my =
previous post.  Here are the results:

https://peakd.com/hive-168588/@crell/object-properties-part-2-examples

Along with an analysis of the pros/cons of each.  As shown there, `inito=
nly` creates backdoors that make any but the most basic cases untennable=
.

--Larry Garfield