Re: [RFC] [Discussion] Clone with
| From: | Larry Garfield | Date: | Thu, 09 May 2024 14:05:28 +0000 |
| Subject: | Re: [RFC] [Discussion] Clone with | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-123286@lists.php.net to get a copy of this message | ||
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