Re: [RFC] [Discussion] Clone with
| From: | Stephen Reay | Date: | Fri, 09 Jun 2023 14:22:06 +0000 |
| Subject: | Re: [RFC] [Discussion] Clone with | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-120552@lists.php.net to get a copy of this message | ||
> On 9 Jun 2023, at 20:55, Larry Garfield <larry@garfieldtech.com> wrote:
>
> On Fri, Jun 9, 2023, at 5:34 AM, Stephen Reay wrote:
>
>> If the property hooks RFC had already passed a vote, I’d suggest that
>> some expansion of hooks could provide a cleaner solution here, but it
>> hasn’t yet (and I understand it’s not desirable to tie the fate of one
>> RFC to another so heavily) so here we are.
>
> You're suggesting some kind of
clone hook on properties?
> That would be interesting, but definitely out of scope for both RFCs at the moment. :-)
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
Hi Larry,
Yes - in the same way that get/set hooks on properties allow much better alternatives to __get/__set
magic methods, a clone hook could provide a better alternative when cloning (I could see two or
three variations of how it might work that seem intuitive for various “clone” and “clone
with” cases).
Agreed, I wasn’t suggesting that it should be attempted as part of this - I was more referencing
that there are other “ugly” magic methods that are planned/expected to be dramatically improved
by a property hook alternative, and thus IMO “this makes the clone magic method a bit fugly” is
of much less concern long term, compared to “this does stuff the user can’t control and is
non-obvious, but we have to maintain this behaviour ‘forever’ because to change it would be a BC
break"
Cheers
Stephen