Re: [RFC] [Discussion] Clone with

From: 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

« previous php.internals (#123286) next »