Nick Cooper schreef:
> Thank you, I am now understanding this much better.
> Could you explain this though, if my understanding is correct the same
> hash is used if the object no longer exists in memory.
> In that case the following should all have the same hash, but they
> don't see output.

not really because creating a second object and stuffing it in
a variablwe is not an atomic action.

> class a1 {}
> $obi = new a1();
> echo get_class($obi).': '.spl_object_hash($obi).'<br/>';
> class a2 {}
> $obi = new a2();

1. the object is created in the engine
2. the object has a pointer assigned to it
3. the variable $obi is assigned, the engine hangs the
   pointer to the newly created object to the zval that represents $obi
4. the previous contents of $obi (internally a zval marked as
'object' with a pointer to an object of class 'a1') is now no longer
referenced by anything in your code, hence the object in question can
be garbage-collected and it's pointer re-used.

(that's my interpretation of what happens, technically I'm sure
I got something wrong ... I don't have any real understanding of the
engines internals)

which is why you see two alternating hashes. the engine
has no way of knowing that you are about to overwrite the
contents of $obi and that as a consequence there will be no more
references to it current contents when it's creating the object for you:

this does what you thought you example should do:

class A {}; class B {}; class C {}; class D {};
        spl_object_hash(new A),
        spl_object_hash(new B),
        spl_object_hash(new C),
        spl_object_hash(new D)

> echo get_class($obi).': '.spl_object_hash($obi).'<br/>';
> class a3 {}
> $obi = new a3();
> echo get_class($obi).': '.spl_object_hash($obi).'<br/>';
> class a4 {}
> $obi = new a4();
> echo get_class($obi).': '.spl_object_hash($obi).'<br/>';
> class a5 {}
> $obi = new a5();
> echo get_class($obi).': '.spl_object_hash($obi).'<br/>';
> Outputs:
> a1: 09d264fcececf51c822c9382b40e3edf
> a2: 45701af64172cbc2a33069dfed73fd07
> a3: 09d264fcececf51c822c9382b40e3edf
> a4: 45701af64172cbc2a33069dfed73fd07
> a5: 09d264fcececf51c822c9382b40e3edf
> 2009/2/12 Jochem Maas <>:
>> Colin Guthrie schreef:
>>> 'Twas brillig, and Jochem Maas at 12/02/09 12:47 did gyre and gimble:
>>>> Colin Guthrie schreef:
>>>>> 'Twas brillig, and Nick Cooper at 12/02/09 11:38 did gyre and gimble:
>>>>>> Outputs:
>>>>>> a1: 09d264fcececf51c822c9382b40e3edf
>>>>>> a2: 45701af64172cbc2a33069dfed73fd07
>>>>>> a3: 09d264fcececf51c822c9382b40e3edf
>>>>>> a4: 09d264fcececf51c822c9382b40e3edf
>>>>>> Thanks let me know how I should proceed with this.
>>>>> Confirmed here. I get different hashes, but the same pattern:
>>>>> a1: 79eff28a9757f1a526882d82fe01d0f3
>>>>> a2: 4cec55f17563fe4436164f438de7a88c
>>>>> a3: 79eff28a9757f1a526882d82fe01d0f3
>>>>> a4: 79eff28a9757f1a526882d82fe01d0f3
>>>>> PHP 5.2.9RC1 with Suhosin-Patch (cli) (built: Feb  9 2009
>>>>> 16:00:42)
>>>>> Copyright (c) 1997-2009 The PHP Group
>>>>> Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
>>>>> You should report the bug:
>>>> it's not a bug. RTFM
>>> Yup I meant to retract my statement after reading your reply but my
>>> message hadn't come through yet to the list and I then got distracted by
>>> something or other.
>> ah. that could have been me :-)
>>> In fairness tho' I did RTFM for the function itself and the stuff you
>>> quoted wasn't listed there, so the docu could do with a little
>>> clarification on that point.
>> granted. the user notes contain the relevant info, the actual docs do indeed 
>> lack
>> detail. Quite a bit of detail regarding this issue actually cropped up on
>> the internals mailinglist which is where I picked up on it.
>> --
>> does a bear shit in the woods? is G.W.Bush a socialist?
>> (given that all the gun-toting Bush supporters have killed all
>> the bears that rhetoric may actually make sense)
>>> Col
>> --
>> PHP General Mailing List (
>> To unsubscribe, visit:

PHP General Mailing List (
To unsubscribe, visit:

Reply via email to