Hi, I originally considered you could retrieve the object key, but if it is not possible by this RFC, I will switch my vote to no.
By storing hash one way it introduces a huge wtf to the language. Cheers, On Dec 17, 2014 8:40 PM, "Rowan Collins" <rowan.coll...@gmail.com> wrote: > On 17/12/2014 22:05, Rowan Collins wrote: > >> For one thing, I think it might be interesting to explore whether real >> objects as keys is actually as difficult as some people are assuming. I can >> naively imagine a few ways it could be implemented that seem in my mind to >> have minimal impact on any array that doesn't use it, but haven't yet seen >> anyone seriously discuss any possible approaches. >> > > In fact, to expand on this, I'm going to stick my neck out and tell > everyone my crackpot theory, which someone who actually understands the > engine will probably demolish in 5 seconds flat, but makes sense in my > mind. :P > > The implementation of arrays could remain the same, with a single pointer > to a second "shadow" HashTable, which would only be initialised when an > object was actually added as a key. Thus the memory overhead would be > reserving a single pointer per array (not per item), and the execution > overhead (for any existing array usage) would be a single if(shadowPointer) > check in a few key places. > > The idea would be that the object would still be hashed - e.g. by default > with spl_object_hash, but with __hash if set - and that key would be stored > in the normal way. However, an extra entry would be added to the shadow > array, as though you had also called $shadow[ $obj->__hash() ] = $obj. > > We might want to do something tricksy to the key, like adding a null byte > at the beginning, to make it less likely for a scalar key and an object > hash to collide. This would also allow further short-cutting in lookups, > since if the first byte was not \0, there would be no chance of a match in > the shadow array. (If it was \0, there might still not be a shadow object, > because null-prefixed strings are actually valid scalar keys, but this > seems unlikely to be a common occurrence.) > > Whenever an array key is taken as *input* (e.g. $foo[$bar], > array_key_exists()), the hash function would be called (much as in the > current RFC), and the corresponding value could be returned directly - the > shadow table would not need to be touched, so performance would be > identical to that of the current proposal. > > A lookup in the shadow array would need to happen only when writing to the > array, and when a key was being given as *output* (e.g. foreach ( $a as $k > => $v ), array_search(), key()). This would happen at the speed of normal > random access, and scale with the number of objects used as keys, not the > number of items in the main array. > > Like I say, I'm sure this is full of holes, and I'll leave it there before > I get too far down a dead end, but I thought it might be a more productive > line of thought than "this will probably never happen". > > Regards, > > -- > Rowan Collins > [IMSoP] > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
