Hi! > 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.
This implies this support is not "real" and we want some other support. I don't think I agree with either. > 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. Was there ever such an ambition? Does somebody have any idea how to properly do it and a reason why? > I hardly see how that would make sense. SplObjectStorate operates with > object identity as determined by spl_object_hash, right? Changing that Now, it does, since there's no other option. However, in the future there may be other options - i.e. objects whose identity is not the same as their memory address. For example, for an object representing number (GMP) or string (UString) their identity is their content, not their memory address. Thus, if you want to use UString as an index, or have an unique set of strings, spl_object_hash would not be your friend. Of course, there's always an option of just telling it - e.g. by providing an option to the ctor. > Right. Somehow python manages to live quite fine with that fact. For some definitions of "quite fine", I presume - I can't see how a hashtable that repeatedly calls user code can be efficient. It probably isn't. > Right. You don't do that when your object implements __hash__ and __eq__. Or, more precisely, you're asked nicely not to do it - because there's no way to actually ensure it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
