Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112728
MIME-Version: 1.0
In-Reply-To: <34d6a045-f7c3-4a77-8b22-378e84b2d1f9@www.fastmail.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>
Date: Sun, 3 Jan 2021 14:28:22 +0000
Message-ID: <CAJpLVh3beDDUieJTnBDJdJHnOZezggWgBfz6eYAQJVF4_jotPw@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Analysis of property visibility, immutability, and
 cloning proposals
From: olleharstedt@gmail.com (=?UTF-8?Q?Olle_H=C3=A4rstedt?=)

2021-01-02 16:06 GMT, Larry Garfield <larry@garfieldtech.com>:
> 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
>> > immutability
>> > in PHP in syntactically clumsy and ugly.  We want to fix that, and tha=
t
>> > 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,
>> > although
>> > I agree entirely that if you have the option of less generic names, us=
e
>> > them).
>> >
>> > So, can we get back to the original post, which is proposing specifics
>> > of
>> > the tools to make that happen? :-)  (Asymmetric visibility and
>> > clone-with,
>> > specifically.)
>> >
>>
>> OK!
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> And also, happy new year!
>
> Happy New Year!
>
> I agree that "objects, but passing by value" would not be the right
> solution. I used to think that would be a good part of the solution, but
> eventually concluded that it would introduce more complexity, not less.
> Eventually, 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 but
> are still mutable then you have a weird situation where sometimes changes
> propagate and some don't (depending on if you have a record or object).
> Making it easier to use objects in a value-esque way will get us closer t=
o
> 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 po=
ked
> in it in order to make it useful in practice (mostly what "initonly" woul=
d
> do), but those holes would introduce other holes we don't want (cloning a=
n
> object from the outside when you shouldn't).

I new language feature needs to be both simple and powerful - it's not
enough to be only powerful. A second problem I see is how asymmetric
visibility would affect the readability of a class, putting extra
strain in understanding it. Thirdly, how does PHP differ from FP
languages like OCaml and Haskell in this regard, neither who uses
visibility in this way? What's acceptable in those languages that
would be unacceptable in PHP?

Olle