Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:7476
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Reply-To: zeev@zend.com
Message-ID: <5.1.0.14.2.20040202143324.05bb27a0@localhost>
Date: Mon, 02 Feb 2004 14:36:22 +0200
To: Stephane Drouard <stephane.drouard@st.com>
Cc: internals@lists.php.net
In-Reply-To: <20040122143711.23632.qmail@pb1.pair.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] __clone() implementation
From: zeev@zend.com (Zeev Suraski)
References: <20040122143711.23632.qmail@pb1.pair.com>

Stephane,

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