On Sun, Oct 7, 2012 at 10:00 PM, Rasmus Schultz <ras...@mindplay.dk> 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 <theanomaly...@gmail.com> > wrote: >> On Sun, Oct 7, 2012 at 7:12 PM, Rasmus Schultz <ras...@mindplay.dk> 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 >>> <jared.willia...@ntlworld.com> 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 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
