Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42724
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 72.14.220.159 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references:x-google-sender-auth;
        b=aK4GfmCROs99zT1FryLd461l60a56HGvDRfC9Zp5Ffvf9wMAsz1++qsCJoh2AkycAN
         LKbz0EV9Mm+teqPwKZEppFkeV++EidiynlZSprJ31rHTMfbmQQQJ6GCPyGLvXybTAwJy
         MV1J8gV4D13zY7VPRc9R0kSrUWDk831oh9YPw=
Message-ID: <e666c3890901200426i328af1ek577db38db04085f4@mail.gmail.com>
Date: Tue, 20 Jan 2009 13:26:53 +0100
Sender: ekneuss@gmail.com
To: "Stan Vassilev | FM" <sv_forums@fmethod.com>
Cc: "internals Mailing List" <internals@lists.php.net>
In-Reply-To: <A0BBE8A87ABF4C5581AD8FD3735BE782@pc>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <bcb7aa500812170931h218ca201j33dfb1bb3dec79de@mail.gmail.com>
	 <1229538590.4955.15.camel@localhost>
	 <e666c3890812171059k98d98f6qfed392b19d54ac2d@mail.gmail.com>
	 <28434894.20081217221911@marcus-boerger.de>
	 <bcb7aa500901190839l7fcff9d3hff19335ba35dab8b@mail.gmail.com>
	 <e666c3890901200128q21959ce3yf3d712c4007e08e1@mail.gmail.com>
	 <A0BBE8A87ABF4C5581AD8FD3735BE782@pc>
Subject: Re: [PHP-DEV] New function proposal: spl_object_id
From: webmaster@colder.ch ("Etienne Kneuss")

Hello,

On Tue, Jan 20, 2009 at 11:47 AM, Stan Vassilev | FM
<sv_forums@fmethod.com> wrote:
>
> Hi,
>
> I had a talk with Marcus, and he has agreed on this proposed solution:
>
> 1) SPL generates a pseudo-random session id/mask (for the current request,
> do not confuse with $_SESSION), which consists of 32 random
> bytes/characters.
> 2) The object is and the handler pointer are used to create a unique
> identifier for the object, by padding each pointer to 16 bytes and joining
> them together.
> 3) The resulting byte sequence is XOR-red with the session mask so the
> object id/handler are not retrievable in userland, and the resulting
> sequence/string is returned.
>
> This is better than spl_object_hash for two reasons:
>
> 1) no printf of numbers, no expensive md5 hashing, no hex conversion.
> 2) no possible collisions
>
> Drawbacks:
>
> 1) might generate some non-printable chars after xor (but this wouldn't
> matter for operation). The idea above can be tweaked to solve this.
>
> The "32-bit string" format is to preserve compatibility with
> spl_object_hash, so it can replace it, instead of introducing a new similar
> function.
>
> I've had no time to look further into this, but Marcus seems to like the
> basic idea, so feel welcome...

Could you please provide an example, with code, in which this function
would be necessary ? (i.e. where you can't use SplObjeccctStorage)

Thanks.

>
> Regards,
> Stan Vassilev
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
>



-- 
Etienne Kneuss
http://www.colder.ch

Men never do evil so completely and cheerfully as
when they do it from a religious conviction.
-- Pascal