Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:23932
Return-Path: <andi@zend.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 76594 invoked by uid 1010); 4 Jun 2006 15:35:33 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 76578 invoked from network); 4 Jun 2006 15:35:32 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 4 Jun 2006 15:35:32 -0000
X-PHP-List-Original-Sender: andi@zend.com
X-Host-Fingerprint: 80.74.107.235 mail.zend.com Linux 2.5 (sometimes 2.4) (4)
Received: from ([80.74.107.235:45023] helo=mail.zend.com)
	by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP
	id 03/9B-49656-3CDF2844 for <internals@lists.php.net>; Sun, 04 Jun 2006 11:35:32 -0400
Received: (qmail 27366 invoked from network); 4 Jun 2006 15:35:03 -0000
Received: from localhost (HELO ANDI-NOTEBOOK.zend.com) (127.0.0.1)
	by localhost with SMTP; 4 Jun 2006 15:35:03 -0000
Message-ID: <7.0.1.0.2.20060604083343.034abe88@zend.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Sun, 04 Jun 2006 08:35:25 -0700
To: Marcus Boerger <helly@php.net>
Cc: Marcus Boerger <helly@php.net>,internals@lists.php.net
In-Reply-To: <334553601.20060604171820@marcus-boerger.de>
References: <795156743.20060603134212@marcus-boerger.de>
	<509342741.20060603183859@marcus-boerger.de>
	<7.0.1.0.2.20060603175211.02208a50@zend.com>
	<20060604030100.1093d2f9@pierre-u64>
	<7.0.1.0.2.20060603181129.0396fc18@zend.com>
	<44823B41.5000608@akbkhome.com>
	<44823C51.7040408@lerdorf.com>
	<64299052.20060604120852@marcus-boerger.de>
	<20060604135241.3beacb32@pierre-u64>
	<1853717276.20060604140317@marcus-boerger.de>
	<fe05d1540606040505o5297a1a8re4ab19f43c36a42c@mail.gmail.com>
	<1912643046.20060604141822@marcus-boerger.de>
	<7.0.1.0.2.20060604071847.03b74850@zend.com>
	<1834492302.20060604165624@marcus-boerger.de>
	<7.0.1.0.2.20060604075725.03d77b20@zend.com>
	<1996647038.20060604170829@marcus-boerger.de>
	<7.0.1.0.2.20060604081244.03dcd938@zend.com>
	<334553601.20060604171820@marcus-boerger.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] Missing __toString() part
From: andi@zend.com (Andi Gutmans)

Yes, I realize that but it doesn't happen today and I don't think we 
couldn't make this a rule (requiring extensions to have unique id's 
per classes). In any case, we can always make it the following string:
"id=<ht table address in hex>#unique id"

Andi

At 08:18 AM 6/4/2006, Marcus Boerger wrote:
>Hello Andi,
>
>   the classname doesn't help, it is the handler that you need. In theory
>you can have two objects with the same id and classname but not with the
>same id and handler table.
>
>best regards
>marcus
>
>Sunday, June 4, 2006, 5:14:46 PM, you wrote:
>
> > At 08:08 AM 6/4/2006, Marcus Boerger wrote:
> >>Hello Andi,
> >>
> >>   it was your own argument that the id itself is not unique when some
> >>time ago somebody wanted to have access to that id from userland. And
> >>it is also the reason for SplObjectStorage the way it is today.
>
> > The object id itself is not unique, but coupled with the class name
> > it is. All this means is that the unique id has to be a string and
> > not a number. I mentioned in the past that it'd be a problem to have
> > a number as the unique id.
>
> >>By 'it hash' nothing to do with hash' i mean that the classname does
> >>not belong into a hash.
>
> > My point is that the string "ClassName#id" is what would be the
> > unique identifier. e.g. that's what toKey() would return (assuming
> > we'd want such a method).
>
> > Andi
>
>
>
>
>Best regards,
>  Marcus