Andi and I have revisited the __clone() implementation and must agree that it wasn't quite right (mainly due to it not working with inheritance).
We have rewritten it now (major change!!!) because we didn't want PHP 5 to be released with a fundamentally flawed mechanism.
Here's our commit message:
Redesign the clone() feature to fix some fundamental flaws in the previous
implementation.
Using clone directly is now done using
$replica = clone $src;
Clone methods must now be declared as follows:
function __clone($that)
{
}
Clone methods in derived classes can call the __clone method of their parent
classes using parent::__clone($that)Zeev
At 16:37 22/01/2004, Stephane Drouard wrote:
I'm currently using PHP4 and I'm evaluating PHP5 for its new exciting features.
I have some remarks, split into distinct posts.
The first one is about the current implementation of __clone():
* a derived __clone() can't call parent::__clone() because $that is only declared for the first __clone() call. So a derived __clone() has to include the code of its parent's __clone(). It's not only bad programming, but it can't work when a parent implements private members.
* when a class implements __clone(), all its derived classes have also to implement it to transfer their own members.
There are a several possibilities to get round the first point, but in order to also simplify __clone() implementation, here is a way it could be implemented, close to __construct() implementation:
* the system firstly does a bit for bit copy of the source object,
* then it calls __clone() (which at worst does nothing, if no class implements it),
* __clone() accesses members using $this to handle those (and only those) that need particular actions,
* this is the responsibility of a derived __clone() to call (or not) parent::__clone().
Advantages:
* same behaviour as __construct(), except that $this is already initialized,
* it guaranties that all members will be transfered, by reference for objects, by copy for the others,
* __clone() just needs to be implemented to handle members that need particular actions,
* derived classes do not need to implement __clone() when one of its parents does,
* no more need of $that.
In terms of performance, I don't think this implementation is bad, because a bit for bit copy is certainly faster than an interpreted member-to-member transfer, except if all members have to be handled in a particular way.
I also consider the __clone() implementation not coherent with its calling syntax.
Indeed "$newObj = $obj->__clone();" lets think of an implementation like this:
<? class Foo { function __clone() { $o = new Foo($this->..., $this->...); $o->...; // eventually return $o; } } ?>
Because __clone() is considered as a copy constructor, it could be implemented in a similar way as for object construction, for example: "$newObj = clone $obj;", "clone" being a language keyword.
Regards, Stephane
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
