Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:7279
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Thu, 22 Jan 2004 20:27:04 +0100
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <88-1582089468.20040122202704@marcus-boerger.de>
To: Stephane Drouard <stephane.drouard@st.com>
Cc: internals@lists.php.net
In-Reply-To: <20040122143711.23632.qmail@pb1.pair.com>
References: <20040122143711.23632.qmail@pb1.pair.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] __clone() implementation
From: helly@php.net (Marcus Boerger)

Hello Stephane,

you're right $that must be available in the derived __clone().

Thursday, January 22, 2004, 3:37:11 PM, you 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




-- 
Best regards,
 Marcus                            mailto:helly@php.net