Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:23909
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <7.0.1.0.2.20060604123950.0d133dc8@zend.com>
Date: Sun, 04 Jun 2006 12:43:28 +0300
To: Andi Gutmans <andi@zend.com>
Cc: internals@lists.php.net
In-Reply-To: <7.0.1.0.2.20060603175211.02208a50@zend.com>
References: <795156743.20060603134212@marcus-boerger.de>
	<20060603143639.GF5355@desario.homelinux.net>
	<509342741.20060603183859@marcus-boerger.de>
	<7.0.1.0.2.20060603175211.02208a50@zend.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] Missing __toString() part
From: zeev@zend.com (Zeev Suraski)

Whichever way we go, the key would have to be either an integer or a 
string (since that's what array indices can be), and going with an 
integer here sounds like a really bad idea (chances of it colliding 
with numeric indices are reasonably high on a 32-bit system).  So if 
we go with (a), it would definitely have to be a string as you 
suggested.  Not sure what's the best way to create a unique, 
one-to-one mapped string representation of an object.  If we can't 
find a solution to that one, then it pretty much brings us to (b).

Zeev

At 03:57 04/06/2006, Andi Gutmans wrote:
>Generally I think it's a good thing to allow to use objects as array indexes.
>There are really two ways of doing it:
>a) Try and find a way to create unique ideas.
>b) Support __toString() and leave it up to the author.
>
>I have a bit of a hard time finding a solution to (a) unless the 
>unique id is a string. Not that I think having it as a string is 
>necessarily a bad thing but I'd be interested in hearing what others think.
>Supporting __toString() is the easiest way to go, especially as it 
>wouldn't lead to BC breaks. It would be up to the author to make 
>that  a unique key like "Db#Person#1" but then they couldn't use 
>that with "print" because the value the class author would want 
>there would probably not be the one he'd want in array access.
>
>Anyone got any thoughts, how bad of a break it would be if we did 
>create a unique id of objects, whether string or int? That's 
>something we probably could do for PHP 6 esp. if string is acceptable.
>
>Andi
>
>At 09:38 AM 6/3/2006, Marcus Boerger wrote:
>>Hello Andrew,
>>
>>Saturday, June 3, 2006, 4:36:39 PM, you wrote:
>>
>> > On Sat, Jun 03, 2006 at 01:42:12PM +0200, Marcus Boerger wrote:
>> >> Hello guys,
>> >>
>> >>   the attached patch closes one more __toString() part. It allows
>> >> to use objects that define __toString as indexes to arrays. What do
>> >> you guys think about this, should we add it or stay with the old
>> >> behavior that didn't allow objects as indexes at all.
>>
>> > Like others who have contributed to the thread I agree that it would be
>> > useful, but I think using __toString() wrong for this.  There is a
>> > confusion two ideas here:
>> >     1. The string representation of an object, probably human
>> >     readable, lucent string.
>> >     2. A unique hash of an object use to identify it programmatically,
>> >     and likely unique.  Probably a non-human friendly, opaque value.
>> > These are not the same thing.  The latter is what, IMO, would be used
>> > for an objects value as an index into an array, not the former.
>>
>> > The latter is available ... currently I do this like so:
>> >     class a{ public function __toString() { return 'an object';}}
>> >     $foo = new a;
>> >     $bar = new a;
>> >     $arr = new array()
>> >     $arr[(string)$foo] = $foo; // The index is "Object id #1"
>> >     $arr[(string)$bar] = $bar; // The index is "Object id #2"
>> > Note that the __tostring method is not used in the cast - a spearate
>> > issue, but needs to be pointed out for this issue.
>>
>> > Therefore my suggested alternative to Marcus' patch is:
>> > When Objects are used in array index context, use the object ID or some
>> > variation.  And, possibly, provide a magic method, or interface to
>> > generate an hash value of an object.
>>
>>We cannot use the object id since that is not necessarily unique.
>>For the same reason SplObjectStorage cannot be done in userland.
>>However what you mention here is right. Other languages offer to
>>magic functions. A stringify one and a hashing one. But then again
>>i don't think we should add yet another magic feature.
>>
>>best regards
>>marcus