At 10:46 AM 2/3/2004 +0200, Stanislav Malyshev wrote:
ZS>> Both are valid points, and they both sound like the same problem from
ZS>> two different angles. I think that the best approach would be to
ZS>> first do an implicit clone (i.e., 'dumb' copy of all of the
ZS>> elements), and then call __cl
ZS>> Both are valid points, and they both sound like the same problem from
ZS>> two different angles. I think that the best approach would be to
ZS>> first do an implicit clone (i.e., 'dumb' copy of all of the
ZS>> elements), and then call __clone(), even if it exists. It should
ZS>> solve both c
> I just had a look at zend_compile.c - it seems as if the variable name
> $that was mandantory:
>
> [...]
> || strcmp(CG(active_op_array)->arg_info[0].name, "that")!=0)) {
> zend_error(E_COMPILE_ERROR, "The clone method
> must be declared as __clone($that)");
> [...]
>
> Why sh
At 09:15 PM 2/2/2004 +0100, Ferdinand Beyer wrote:
I like the new way very much but I dislike that PHP tells me how to
name a function parameter. __set() and __get(), for instance, do not
force fixed argument names either, do they?
Some people use their own naming convention for parameters and
will
== Quote from Ferdinand Beyer ([EMAIL PROTECTED])'s article
> I like the new way very much but I dislike that PHP tells me how to
> name a function parameter. __set() and __get(), for instance, do not
> force fixed argument names either, do they?
I agree.
Anyway, do we now need $that to be passed
On 2 Feb 2004 at 21:57, Andi Gutmans wrote:
> Because it's a good way of retrieving the to-be-cloned object (no
behind
> the scenes magic), and in my opinion, it's cleaner because
everyone's clone
> functions will look the same and it'll make it easier to understand
them.
> Why do you care so
On Mon, 2 Feb 2004, Andi Gutmans wrote:
> At 02:42 PM 2/2/2004 -0500, George Schlossnagle wrote:
> >If you force the parameter to be name $that, what's the point of requiring
> >it to be passed at all? Seems analogous to having all methods be required
> >to pass $this as their first parameter.
>
On Feb 2, 2004, at 2:57 PM, Andi Gutmans wrote:
At 02:42 PM 2/2/2004 -0500, George Schlossnagle wrote:
If you force the parameter to be name $that, what's the point of
requiring it to be passed at all? Seems analogous to having all
methods be required to pass $this as their first parameter.
Bec
At 02:42 PM 2/2/2004 -0500, George Schlossnagle wrote:
On Feb 2, 2004, at 2:39 PM, Andi Gutmans wrote:
At 07:32 PM 2/2/2004 +0100, Ferdinand Beyer wrote:
On 2 Feb 2004 at 14:36, Zeev Suraski wrote:
> Clone methods must now be declared as follows:
> function __clone($that)
> {
> }
I just had a lo
On Feb 2, 2004, at 2:39 PM, Andi Gutmans wrote:
At 07:32 PM 2/2/2004 +0100, Ferdinand Beyer wrote:
On 2 Feb 2004 at 14:36, Zeev Suraski wrote:
> Clone methods must now be declared as follows:
> function __clone($that)
> {
> }
I just had a look at zend_compile.c - it seems as if the variable name
At 06:49 PM 2/2/2004 +, Stephane Drouard wrote:
== Quote from Zeev Suraski ([EMAIL PROTECTED])'s article
> Both are valid points, and they both sound like the same problem from two
> different angles. I think that the best approach would be to first do an
> implicit clone (i.e., 'dumb' copy of
At 07:32 PM 2/2/2004 +0100, Ferdinand Beyer wrote:
On 2 Feb 2004 at 14:36, Zeev Suraski wrote:
> Clone methods must now be declared as follows:
> function __clone($that)
> {
> }
I just had a look at zend_compile.c - it seems as if the variable name
$that was mandantory:
[...]
|| strcmp(CG(active_
At 01:26 PM 2/2/2004 -0500, Adam Bregenzer wrote:
On Mon, 2004-02-02 at 13:18, Stephane Drouard wrote:
> Another idea for case 1 could be to be able to call parent::__clone
> even if the class does not implement it and have the bit for bit copy
> (but just for the base class).
I also think a defaul
== Quote from Zeev Suraski ([EMAIL PROTECTED])'s article
> Both are valid points, and they both sound like the same problem from two
> different angles. I think that the best approach would be to first do an
> implicit clone (i.e., 'dumb' copy of all of the elements), and then call
> __clone(), ev
On 2 Feb 2004 at 14:36, Zeev Suraski wrote:
> Clone methods must now be declared as follows:
> function __clone($that)
> {
> }
I just had a look at zend_compile.c - it seems as if the variable name
$that was mandantory:
[...]
|| strcmp(CG(active_op_array)->arg_info[0].name, "that")!=0)) {
On Mon, 2004-02-02 at 13:18, Stephane Drouard wrote:
> Another idea for case 1 could be to be able to call parent::__clone
> even if the class does not implement it and have the bit for bit copy
> (but just for the base class).
I also think a default __clone method that does a bit for bit copy wou
At 20:18 02/02/2004, Stephane Drouard wrote:
== Quote from Zeev Suraski ([EMAIL PROTECTED])'s article
> 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!!!) be
On 2 Feb 2004 at 14:36, Zeev Suraski wrote:
> Using clone directly is now done using
> $replica = clone $src;
> Clone methods must now be declared as follows:
> function __clone($that)
> {
> }
Finally! I've suggested this change several times before
([EMAIL PROTECTED]) but no one was interested
== Quote from Zeev Suraski ([EMAIL PROTECTED])'s article
> 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 w
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 co
I was told earlier that this is the correct way to do it:
public function __clone()
{
$this = parent::__clone();
$this->... = $that->...;
...
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Marcus,
> you're right $that must be available in the derived __clone().
You will solve one problem: being able to call parent::__clone(), but it won't remove
the constraint on derived classes (declaring members) to implement __clone() when one
of its parents implements it.
This is just to limi
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 cur
23 matches
Mail list logo
