Posted by Michael Fesser on 12/19/07 23:52

..oO(Steve)

>"Michael Fesser" <netizen@gmx.de> wrote in message
>news:71sim318adncjtc8m13mp0cek2kn1sbvfh@4ax.com...
>>
>>>the only difference in php is that rather than the
>>>handle pointing to a memory address where information is stored, this php
>>>handle points to a symbol table entry where information is stored.
>>
>> Exactly. A pointer contains a memory address, a handle doesn't.
>
>again, this is irrelevant to behavior. the end result is the same whether
>the data is in memory or in a symbolic table. i'm talking about behavior.
>i'd be interested in that level of detail if i weren't using a *scripting*
>language. for most however, it is enough to describe the behavior of php
>references as pointers...especially for those whom have a background in
>working with pointers.

Especially those who have a background in pointers should know that PHP
references behave differently (which BTW is explicitly mentioned in the
manual and explained with an example).

>>>in php, a reference (or byref) behaves *IDENTICALLY* to a c/c++ pointer.
>>
>> Nope. References in PHP behave like references in C++, they're just
>> alias names for the same data structure.
>
>did you miss a 'not' or 'don't' somewhere in there?

No.

>you just agreed with me
>yet preficed it with 'nope'. as for pointer v. reference in a specific
>language?

PHP references behave like C++ references.
PHP references don't behave like C++ pointers.

>>>to be accurate, the handle needn't be a number.
>>
>> Correct, but it probably makes it easier and more efficient.
>
>not sure that it does, fwir, the lookup on the symbol table is essentially
>like using a key on an array, and there's no speed difference there whether
>your key is numeric or alpha or both. were it stored in a db, i'm sure that
>would be true though.

The objects themselves in PHP 5 are not necessarily stored in the symbol
table, they could be stored elsewhere, where a numeric index might speed
things up. But that's just a guess, I really don't want to look through
the sources that deep.

>right, which is why i don't trifle with the technical differences we are
>both aware of when i say pointer, reference, or alias. in the end, and no
>matter how many -> are inbetween the variable and the object, the object is
>always returned. i do get technical when using a technical language, just
>not in php...esp. on usenet. i'm considering the audience.

Even in PHP sometimes the technical details are required in order to
solve a problem or explain a particular behaviour. For example you can
use foreach with references:

foreach ($foo as &$bar) {
...
}

Dependent on what you do with $bar and whether it was used previously,
some strange things might happen, which can only be explained if you
know what goes on behind the scenes.

>> That entry _is_ the handle. The associated object can be stored
>> elsewhere (I don't know how the ZE handles this internally, doesn't
>> matter anyway).
>
>you mean the 'z entry'

Nope, I meant the Zend Engine itself. I don't know how and where it
actually stores its objects. The symbol table probably just contains the
object handle, the object itself could be anywhere else.

>>>$a gets a new handle in the symbol
>>>table whereby the entry data is copied into it from $foo. $b is an alias
>>>of
>>>$foo.
>>
>> Let's look at it this way:
>>
>> $foo = 5;
>>
>> $a = $foo;
>> $b = &$foo;
>>
>> Same thing. Let the 5 be the internal number (the handle) of any object.
>
>again, in the order of operations, 5 would have been the result of the rhs
>creation of the object using the keyword 'new'.

Yep.

>$foo is now an alias for
>that object. but, proceed.

$foo is just the name (or label) for a symbol table entry with the value
'5'.

>> The first assignment copies the symbol table entry of $foo into $a.
>
>no, it changes the descriptors of the entry such that ref_count is two and
>is_ref remains 0. upon the first write operation done on $a, the $foo entry
>is copied into an entry just for $a and the values being changed in $a will
>be seen in that entry.

Correct. That's what I meant some lines further down with "This is a bit
simplified ... from the programmer's POV" etc. Under the hood there's
copy-on-write, but from the outside it looks like an immediate copy.

This is about _behaviour_. ;)

>> The second assignment doesn't make a copy, but instead makes
>> $b an alias/a reference to the symbol table entry of $foo:
>
>kind of, however from what i recall, the entry table looks almost identical
>before a write operation. the difference in the byref entry is that is_ref
>will be true...$b will have simply increased the ref_count - my crippled
>memory notwithstanding of course.

All correct, but not part of the issue here.

>>>$a is NOT a copy of the $foo's object handle - that would be an
>>>*alias*...a
>>>*reference*.
>>
>> $b is the reference, $a is the copy. Back to our object handle, the
>> situation would look like this:
>
>if $a is to be a copy of $foo, it will not have the same handle.

I mean the object handle, the object identifier. Of course the same
handle can be stored in different variables (I consider this copies).
That's what you're doing all day when working with objects in PHP 5.
Nevertheless all these handle copies still identify the same object.

>right, we have no confusion there...much less anywhere else i think. i'm
>just a bit more comfortable using descriptive terms in describing how =& and
>function arguments are performed in php. of course that changes with
>context...but, php is a scripting language. the audience is too, more
>relaxed.

No problem with that.

The point was more or less just that there's still a difference between
= and =& in PHP 5, even when working with objects. If saying "objects in
PHP 5 are passed by reference by default" would be true and taken word
for word, then this code (taken from the linked site):

$a = new stdClass;
$b = $a;
$a = 'baz';

would destroy the object. But it doesn't. The object is still there and
accessible with $b. And in order to understand why it works this way,
you have to understand how objects are handled internally. Of course
only if you want. For most developers and in most situations it won't
matter anyway.

>> Mentioned in the first paragraph:
>>
>> | If you're among the crowd who have migrated an OOP based application
>> | from PHP4 to PHP5, then I'm sure you've heard the expression "Objects
>> | are copied by reference by default in PHP5". Whoever told you that,
>> | was lying.
>
>oh, so the 'whom' is 'whoever'...i'm grinning right now. :)

Yep. But when PHP 5 came up, I've read more than once about this "new
object handling by references" and such. I think I've even read it in
the PHP manual one time, but I'm not sure about it. All recent versions
explicitly mention the object handles.

>unless i read the article, which most won't, it seems as though you are
>talking about someone who posted a comment in the thread. i don't see anyone
>lying here.

No. It was just an addition to explain the difference between = and =&.

Micha

[Back to original message]