Edit report at https://bugs.php.net/bug.php?id=65718&edit=1
ID: 65718
Comment by: metamarkers at gmail dot com
Reported by: metamarkers at gmail dot com
Summary: __inClone() magic method to alter an object's
inclusion in clones
Status: Wont fix
Type: Feature/Change Request
Package: Class/Object related
PHP Version: Irrelevant
Block user comment: N
Private report: N
New Comment:
Valid points. Thanks for reading.
Previous Comments:
------------------------------------------------------------------------
[2013-09-20 04:10:47] requi...@php.net
That decision should be up to Foo, not up to Bar. If Foo is unaware that it no
longer has a $bar member then that could introduce all sorts of unexpected and
difficult to trace bugs.
Besides, PHP does not do deep copies during cloning anyways.
Implement Foo::__clone() such that it would normally clone all its members.
Then
you can
(a) Make it not clone its $bar and instead unset() it
(b) Implement a private Bar::__clone() so attempting to clone $bar raises a
fatal
"Call to private Bar::__clone from context 'Foo'"
(c) Implement a public Bar::__clone() and throw an Exception so attempting to
clone $bar fails
Whichever way, Foo is responsible for knowing that Bar cannot be cloned and
should
adjust its own behavior accordingly.
------------------------------------------------------------------------
[2013-09-20 03:50:39] metamarkers at gmail dot com
Description:
------------
It would be nice if an object could determine whether or not it should be
included in a clone, by returning a value that should be used in its stead, or
an
updated clone of itself, or anything of the like.
Test script:
---------------
class Foo { }
class Bar {
public function __inClone ( $clone ) {
return $clone instanceof Foo ? null : $this;
}
}
$foo = new Foo();
$foo->bar = new Bar();
$foo2 = clone $foo;
isset($foo2->bar); // false
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=65718&edit=1
