Re: [RFC] [Discussion] Clone with
| From: | Lynn | Date: | Wed, 28 Jun 2023 07:53:19 +0000 |
| Subject: | Re: [RFC] [Discussion] Clone with | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-120710@lists.php.net to get a copy of this message | ||
On Wed, Jun 28, 2023 at 9:11 AM Nicolas Grekas <nicolas.grekas+php@gmail.com>
wrote:
> > Also, I'm wondering whether it's worth the complexity to add support for
> > another magic method,
> > or would we be fine without this feature and its benefits? To put it
> > another way: how much
> > complexity is it worth to fix the problem of the wasteful deep cloning?
> > Does anyone have
> > an informed answer/opinion?
> >
>
> It's not only solving the problem of wasteful deep cloning, but also
> solving the problem of validating while cloning (the one Alexandru
> highlighted.)
> So yes, I think it's worth it. Also because to me shipping a solution with
> known shortcomings is likely going to turn into technical debt for the
> community and even for internals in the future.
>
> I saw your message about postponing this to 8.4. I think that's fair.
> Complex topic :)
>
> Nicolas
>
In terms of complexity, what if we could use property access hooks to
define how it should be cloned? I think this will cover a lot of scenarios
without having to think about the complexity of the clone function itself.
These hooks should probably be called _before_ the clone method called.
```php
<?php
enum MyState {
case New;
case Cloned;
}
final class MyObject
{
public MyName $name {
// default behavior as it is right now
clone => $value,
}
public MyValue $value {
// deep clone
clone => clone $value,
}
public readonly MyState $state = MyState::New {
// don't use either and mark it as not being constructed via "new"
clone => MyState::Cloned,
}
}
```