On Thu, 15 May 2025 at 13:56, Stephen Reay <php-li...@koalephant.com> wrote: > > > > > > On 15 May 2025, at 16:44, Andreas Hennings <andr...@dqxtech.net> wrote: > > > > On Thu, 15 May 2025 at 08:24, Stephen Reay <php-li...@koalephant.com> > > wrote: > > [..] > >> > >> > >> I may be missing something here.. > >> > >> So far the issues are "how do we deal with a parameter for the actual > >> object, vs new properties to apply", "should __clone be called before or > >> after the changes" and "this won't allow regular readonly properties to be > >> modified". > >> > >> Isn't the previous suggestion of passing the new property arguments > >> directly to the __clone method the obvious solution to all three problems? > > > > What exactly should happen then? > > Would the __clone() method be responsible for assigning those properties? > > Or does the __clone() method get the chance to alter the values before > > they are assigned? > > (this would mean they have to be passed by reference) > > I think this last option is the best, because the values in the array > > can be changed without any readonly constraints. > > > > Another option I was thinking of would be to call __clone() after the > > changes are applied, and pass both the original object and the array > > of changes as first parameter. > > But I think this is a dead end. > > > > -- Andreas > > > >> > >> There's no potential for a conflicting property name, the developer can > >> use the new property values in the order they see fit relative to the > >> logic in the __clone call, and it's inherently in scope to write to any > >> (unlocked during __clone) readonly properties. > >> > >> > >> > >> Cheers > >> > >> Stephen > >> > >> > >> > > > > I would suggest that the __clone method should be directly responsible for > making any changes, just as it is now when it comes to deep cloning or > resetting values. > > Yes I realise it means developers need to then opt in and provide the > functionality to support `clone $foo with(bar: "baz")` or whatever syntax is > used.
I don't really like this. It would mean that if you add an empty __clone() method, it would prevent all of the automatic setting of values. > > If the properties are public properties, there's nothing stopping someone > writing their own clone_with() in userland now; If someone is using readonly > properties I'd suggest they want to specifically manage updates to those > properties themselves anyway. But they already do that in the ->withXyz() methods. A public non-readonly property can be set from anywhere without validation or clean-up, so by default the __clone() method would want to leave it alone. A readonly or non-public property can only be initialized from within the class, so the ->withSomething() method would be the place for cleanup and validation. The default behavior of an empty __clone() method should therefore be to just allow all of the properties being set as they would be without a __clone() method. > > Additionally it means "clone with" would be usable for non-public properties > at the discretion of the developer writing their code. This is already the case, because that "clone with" for non-public properties can only happen from within methods of the same class (hierarchy). -- Andreas > > The mental model is also very clear with this: copy the object in memory, and > then call __clone(), with the arguments passed to the clone action - which > may be none in the case of code that doesn't accept any clone arguments. The > only change from the current model is that it *may* be passing arguments. > > Cheers > > Stephen > > >
