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
