Am 27.10.2014 08:09 schrieb "Stas Malyshev" <smalys...@sugarcrm.com>: > > > I don't like this, mainly because it blocks a future direct use and storage > > of objects as keys in an array, i.e. what SplObjectStorage does. > > It does not. It just allows the objects to control how they are seen > when they are used as keys in regular PHP arrays. That does not prevent > SplObjectStorage or anything else from doing whatever one wants.
I did not mean SplObjectStorage would be affected negatively. Just used it as the best known example for something that directly supports objects themselves as keys. Once your proposal is in the language, you will never, in the future, be able to add real support for objects as keys, because the semantics is blocked. I do understand where your proposal is coming from and what it is trying to accomplish. But I think, at least, that it should clearly spell out that any ambition to really support objects as array keys in the base language, will then be given up. > I personally would say SplObjectStorage probably should respect __hash if > provided, but we can discuss it separately. I hardly see how that would make sense. SplObjectStorate operates with object identity as determined by spl_object_hash, right? Changing that to use your key derivation method, would break that contract. Okay, maybe it could make sense by adding a second set of attach/detach methods that work this way when the objects support the new hash method. > Storing objects in the hashtable would really require rewriting the whole > hashtable and would probably be very inefficient as you'd have to call > PHP code each time you compare two objects in the chain. Right. Somehow python manages to live quite fine with that fact. > Moreover, modifying such objects would probably create havoc. Right. You don't do that when your object implements __hash__ and __eq__. best regards Patrick
