Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123286
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-443-g0dc955c2a-fm-20240507.001-g0dc955c2
Precedence: bulk
MIME-Version: 1.0
Message-ID: <eddf0192-5387-468b-a81c-7ec24b3a7f17@app.fastmail.com>
In-Reply-To: 
 <CAB-BujYMTyjp54d=TiTtPq8d-ESez1=X-OavUoVe+w0td8LUkA@mail.gmail.com>
References: 
 <CAH5C8xUn2wotLg0L7KZHoOGf3q-UqbL=47p2PLzK_mOBb=MJXQ@mail.gmail.com>
 <CAOWwgpncdhKvhwiAFUh_c_8+_vr=u9HhYxws_WZArh7W3Fi0xw@mail.gmail.com>
 <799ae864-6e25-4196-a5ce-0d74600a8378@app.fastmail.com>
 <CAAwdEzCbRdDHN=WYZy_jnyrM9USG9k9bxn=AW-KVWB8iSrBmrQ@mail.gmail.com>
 <CAOWwgp=Ch2iwOzxooiRcfk3WYMz-eYmQ51M-UP2Hh3bDogX5uw@mail.gmail.com>
 <CAH5C8xV76ou5Edpvq-vzb6RytW5-3uGanX+Sqf92-qnH26ccBw@mail.gmail.com>
 <CABdc3WqsVq4Jo1tt5EOevQ15aXhLA1+6SRmSENc8-K7SHX20Hg@mail.gmail.com>
 <280bcea8-9483-4191-80d3-81763a988290@app.fastmail.com>
 <CAH5C8xVhiByYaRqF8nKqj=m=xanPt=WDOPOy0Rt3G48pNutJ6Q@mail.gmail.com>
 <5db38bc4-a6fd-4cb7-b10d-3ad1a590888c@app.fastmail.com>
 <CAAwdEzCNYcCJC=qzCNwoCo_GsVM=ZiBvo3kSd5_LM=7U=+7u3g@mail.gmail.com>
 <39511e44-93cb-4fde-b0ec-ce24ee88f4be@app.fastmail.com>
 <CAAwdEzCbUbwX1+ZyhAC0R_R0uYt5zNirz6vNO07=Ao+zr9eN+A@mail.gmail.com>
 <CAOWwgpncC043ciO7HTuX954bfb+KWZ903zxKhQT-VigZh0WyYg@mail.gmail.com>
 <e13aa53c-1c7c-47dd-8179-ca64ec180344@app.fastmail.com>
 <CAH5C8xXqLkyBee1U5pEZWP+VvktZULS2TyPPTpaZ0_V_c9oVLw@mail.gmail.com>
 <07b0f341-f062-45fe-ade0-52cf75003895@app.fastmail.com>
 <CAB-BujYMTyjp54d=TiTtPq8d-ESez1=X-OavUoVe+w0td8LUkA@mail.gmail.com>
Date: Thu, 09 May 2024 14:05:28 +0000
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Clone with
Content-Type: text/plain
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, May 9, 2024, at 1:10 PM, Andreas Hennings wrote:

>> Where all properties are readonly, and if an object those are *also* readonly, and all are assigned in the constructor...
>>
>> Yeah, that ideal case is kinda narrow, and likely will remain so for a long while yet.
>>
>> Whichever order it goes in, that should be documented explicitly and the reasoning for it included.  (Feel free to pilfer my examples above extensively if that helps.)
>>
>> As for the syntax itself, my preferences, in order, would be:
>>
>> 1. clone $foo with (...), where (...) follows named-argument syntax in all its variants and forms, which includes ...$arr.
>>
>> 2. clone $foo with $array, where $array is an honest to goodness assoc array/array literal, created by any means the developer wants.
>>
>> Either of those are equally expressive; the first is, IMO, cleaner and easier to read/type, and probably nicer on static analysis tools, but they're still both equally expressive.
>>
>> Anything less than that is, IMO, creating unnecessary confusion about how the syntax behaves that will trip up developers left and right.
>>
>> --Larry Garfield
>
> Hello list,
> First, I am very much in favor of the named-argument syntax `clone
> $obj with (key: $value, ...)`, with support for argument unpacking.
>
> The syntax is well suited for the most common case, which is regular
> wither methods for one or more known properties.
> I don't like the array syntax as a default. It has inferior DX for
> regular withers, and possible performance impact from the temporary
> array.

I agree.

> For the execution scope ideas:
> I kind of like the idea to have a special object state or scope effect
> where some properties are writable that otherwise wouldn't be.
> However, I don't like this kind of concept being introduced as a
> special case only for this clone execution scope.
> E.g. the current "readonly" implementations actually means write-once
> + write-private, applied on property level. But in the clone scope it
> would mean something different.

Yet again, readonly was badly designed and it's biting us. :-(  This is one of the reasons Ilija and I are planning to take another swing at asymmetric visibility, which solves nearly all of these issues.  Or, it will if we can avoid bikeshedding over the syntax again...

--Larry Garfield