Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:63275 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 46433 invoked from network); 8 Oct 2012 04:13:11 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 8 Oct 2012 04:13:11 -0000 Authentication-Results: pb1.pair.com smtp.mail=theanomaly.is@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=theanomaly.is@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.42 as permitted sender) X-PHP-List-Original-Sender: theanomaly.is@gmail.com X-Host-Fingerprint: 209.85.215.42 mail-la0-f42.google.com Received: from [209.85.215.42] ([209.85.215.42:51890] helo=mail-la0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 97/F6-07529-6D252705 for ; Mon, 08 Oct 2012 00:13:10 -0400 Received: by mail-la0-f42.google.com with SMTP id e6so2005131lah.29 for ; Sun, 07 Oct 2012 21:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zwSeQoUYfr5z5nxodOWZxqsvwj2De/O5UvNmlFG5gy8=; b=PfLET7GSroiaZaubfb3yAyTQXDbXf8lMk+MlDPuDff6XMUol5UF5zcsmW0UFeLjRiY 4AlbauPQ/MX+hGJ9AD54XHnbNu6QzbA8HtXF+idknetKgRSjCJo7nRVO68hVdxz/8+i1 m9CiJwsIEMmt8MGRbQeMFKZ5Xv9yt+FvLiz1LCk4W/c0SmGcHoOOJ1qoBMYffpLMEo6Y Q3Wqsrr5kEjGbqzS6z/AZf9UVoKkk9zR7VYAXfaRIrGVOCo7e/EcCZqbDeZkrowS7v4Y kiQx+viImfDO9TyvwtmUOa+Vp7z+oxISeuvSTErv7CZq44dvudej3QKWuAat4LUne1t2 9Abw== MIME-Version: 1.0 Received: by 10.112.38.65 with SMTP id e1mr6282644lbk.15.1349669587296; Sun, 07 Oct 2012 21:13:07 -0700 (PDT) Received: by 10.112.12.178 with HTTP; Sun, 7 Oct 2012 21:13:07 -0700 (PDT) In-Reply-To: References: <20121007200604.CGVT23973.aamtaout03-winn.ispmail.ntl.com@p2> Date: Mon, 8 Oct 2012 00:13:07 -0400 Message-ID: To: Rasmus Schultz Cc: internals@lists.php.net Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [PHP-DEV] Re: Arrays which have properties of sets From: theanomaly.is@gmail.com (Sherif Ramadan) On Sun, Oct 7, 2012 at 10:00 PM, Rasmus Schultz wrote: > looks like you're right - spl_object_hash() does in deed work... I > guess I was mislead by some of the notes people made in the > documentation... perhaps these should be moderated, and the > documentation should be update to clear up some of the mystery and > confusion that seems to surround this function? > > http://us3.php.net/manual/en/function.spl-object-hash.php#110242 > > "Changing the state of an object does not affect the result" - well of > course not, since spl_object_hash() does not in fact seem to hash the > "object", or at least not it's state. > Well, here the user actually makes a mistake in the last line. They var_dump(spl_object_hash($foo_obj)) instead of $foo_obj2, which is the new object the intended to test. But yes, the hash is unique per object and doesn't consider state. > http://us3.php.net/manual/en/function.spl-object-hash.php#95666 > > "The unique identifiers of destroyed objects can and will be reused" - > this could be demonstrated more clearly by using unset() ... though I > understand it now, this example made me think at first that keys would > just be reused at random... > I guess their intent here is to elaborate on the documented behavior that the hash may be reused if the object is destroyed. Though you can say that when you destroy and reinitialize the object of the same class in the same variable that it will necessarily get the same exact hash. It likely won't, but obviously there's no guarantee of that, which is why it's documented that way. > http://us3.php.net/manual/en/function.spl-object-hash.php#94647 > > "It seems that when switching scopes, the last one is repeated" - > that's not at all what's happening in this extremely misleading > example... rather, spl_object_hash(new stdClass()) creates an object > that immediately falls out of scope and gets destroyed, at which point > the same key may be reused in a different scope OR even in the same. > Sure. > http://us3.php.net/manual/en/function.spl-object-hash.php#94060 > > this seems to demonstrate an alternative approach, but as pointed out > by Sherif, this is not the same thing at all. > Right, this isn't a hash in the sense that a hash is normally a fixed-length checksum of some sort. The implementation is poor in that I could reassign the hash to the same object a dozen times over and get a dozen different hashes every time. You don't expect to send the string "foo" to md5() a dozen times and get a dozen different hashes, just like you shouldn't expect that from spl_object_hash(). It doesn't uniquely identify anything. The implementation of uniqid() without arguments is the equivelant of a hex encoded microtime(), because that's essentially all it is internally. > http://us3.php.net/manual/en/function.spl-object-hash.php#91164 > > "The spl hash will always be the same for a given object, regardless > of content" - this is definitely not the case. > > http://us3.php.net/manual/en/function.spl-object-hash.php#90296 > http://us3.php.net/manual/en/function.spl-object-hash.php#87422 > > Both attempt to implement spl_object_hash() in older versions of PHP, > but both are extremely misleading since they have essentially nothing > in common with spl_object_hash() as such. > Yea, there's lots of pretty bad code in user notes. That's nothing new :) > http://us3.php.net/manual/en/function.spl-object-hash.php#76220 > > This actually clarifies something things that probably should be > explained in the documentation. It is "Return Values A string that is unique for each currently existing object and is always the same for each object." from php.net/spl-object-hash :) > > It's perhaps the worst case of misleading user comments to date... ;-) > Nah, I've seen worse. I've removed the notes you've mentioned that provide bad code. Cheers! > > On Sun, Oct 7, 2012 at 7:51 PM, Sherif Ramadan wrote: >> On Sun, Oct 7, 2012 at 7:12 PM, Rasmus Schultz wrote: >>> the manual states, "The implementation in SplObjectStorage returns the >>> same value as spl_object_hash()" - so I don't know how this would >>> really work any better than a custom implementation. >>> >>> perhaps safer would be to simply implement a collection-type that >>> requires the classes of elements in the collection to implement an >>> interface, exposing a unique key... and for objects that don't have a >>> unique key, generate sequential keys from a static counter in each >>> class... not ideal if you want to implement a document store that can >>> store "anything", since now every stored object/class needs to provide >>> a key... >>> >> >> How is that safer? If anything this introduces every aspect of being >> unsafe since relies on a user implementation that may or may not exist >> and may or may not be unique. As opposed to spl_object_hash, which can >> actually identify objects uniquely by looking at the internal symbol >> table that exposes all the objects in memory. >> >>> On Sun, Oct 7, 2012 at 4:06 PM, Jared Williams >>> wrote: >>>> >>>> See SPL's SplObjectStorage. That allows object instances as keys. >>>> >>>> Jared >>> >>> -- >>> PHP Internals - PHP Runtime Development Mailing List >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >