> 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.
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.
Additionally it means "clone with" would be usable for non-public properties at
the discretion of the developer writing their code.
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
