Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:23893 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 92431 invoked by uid 1010); 3 Jun 2006 21:15:59 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 92416 invoked from network); 3 Jun 2006 21:15:59 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Jun 2006 21:15:59 -0000 X-PHP-List-Original-Sender: gwynne@skytag.com X-Host-Fingerprint: 208.97.132.53 ip-208-97-132-53.dreamhost.com Linux 2.4/2.6 Received: from ([208.97.132.53:51920] helo=spunkymail-a13.dreamhost.com) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id BF/B1-49656-E0CF1844 for ; Sat, 03 Jun 2006 17:15:58 -0400 Received: from [192.168.1.104] (c-24-147-151-210.hsd1.ma.comcast.net [24.147.151.210]) by spunkymail-a13.dreamhost.com (Postfix) with ESMTP id 9A0C8129B23 for ; Sat, 3 Jun 2006 14:15:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v749.3) In-Reply-To: <4481C354.10207@lerdorf.com> References: <795156743.20060603134212@marcus-boerger.de> <18CE805D-C032-4B64-950A-119E46287AF5@prohost.org> <4481B92E.2030802@lerdorf.com> <4481C354.10207@lerdorf.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-ID: <4AC4FA24-6E74-492A-A3CF-DD75CF26390C@skytag.com> Content-Transfer-Encoding: 7bit Date: Sat, 3 Jun 2006 17:15:50 -0400 To: internals@lists.php.net X-Mailer: Apple Mail (2.749.3) Subject: Re: [PHP-DEV] Missing __toString() part From: gwynne@skytag.com (Gwynne) On Jun 3, 2006, at 1:13 PM, Rasmus Lerdorf wrote: >> RL>>I don't understand why using the object as an index would >> trigger a RL>>__toString() call. PHP's array indices are not >> defined to be strings, RL>>so I don't see this as being a string >> context use and thus >> RL>>__toString() shouldn't be called. >> If so, what should be the actual key in the hash? > I am sure we could come up with some sort of hashing mechanism that > would uniquely identify an object. And perhaps even expose it to > the user with a __hashOf(). But again, I am not sure we want to > open up that can of worms. Like I said, I think this is the more > correct approach and that we shouldn't try to use a magic __toString > () call here to attempt to emulate this. I'm new to this list, so I apologize if I'm out of line in commenting here, but it's my opinion that the advantages offered by a __hash() magic function would outweigh the inevitable complexity and issues involved. I imagine that it would be a strict semantic: If the class of the object being indexed into the array doesn't define a magic __hash() function, it would be a warning or even fatal error; no attempt would/should be made to calculate a hash based on anything other than what the object is willing to call itself. Gwynne SkyTag Software