|
Posted by Tim Van Wassenhove on 01/13/06 17:36
On 2006-01-13, Mladen Gogala <gogala@sbcglobal.net> wrote:
> On Fri, 13 Jan 2006 15:12:29 +0000, Mladen Gogala wrote:
>
>> On Thu, 12 Jan 2006 19:01:10 -0800, Chung Leong wrote:
>>
>>> Here's a little brain teaser distilled from a bug that took me a rather
>>> long time to figure out. The two functions in the example below behave
>>> differently. The difference is easy to spot, of ocurse. The challenge
>>> is correctly explaining why this is so. Why does the second function
>>> seemingly corrupt the cloned copy of an object?
>>
>> It doesn't. You are not writing to the clone, you are writing to the
>> original. You are setting the original data to "", not the clone. Clone
>> is a bitwise copy, not a reference. If you want it to be something else
>> then a bitwise copy, you have to define the __clone function. What you
>> should have written in place of "clone" is $clone =& $obj; Then the
>> assignment would work and the function would return a reference to
>> the original object, which is also passed by reference.
Changing the statement below to: $attr = $obj->attributes would already make
the curiosity disappear.
> $attr =& $obj->attributes;
I still think it's because after this statement the container that holds the
$obj->attributes will now have is_ref = 1 which seems to lead to a copy of this
container when $obj is assigned to $clone ($clone = $obj). For some reason php
doesn't seem to make a deep-copy of the array but simply makes an array with
references to the original array elements.
--
Met vriendelijke groeten,
Tim Van Wassenhove <http://timvw.madoka.be>
Navigation:
[Reply to this message]
|