Hi! > This RFC proposes that we store the hash of an object instead of the > actual object. That's simply not useful to me
Fair enough, but this is not only about what is useful personally to you. > and likely prevents us > from adding support for objects as keys in the future should we want No it does not. It was already explained several times. If it is ever introduced, it can be used for objects that do not explicitly request functionality in this RFC by enabling __hash() with no BC issues, since this RFC only affects classes that explicitly ask for this specific functionality. So if you, according to the above, would never use __hash, absolutely nothing would prevent you from using objects as keys if it ever happens (which it probably won't in the next 2-3 years). > In addition, it adds yet another behavior to arrays which do so many > things already. I would much rather have structures that focus on It's exactly the same behavior, just available for select objects now. Arrays don't do anything new, they still store key/value pairs, objects do something new to enable you doing more things with value objects. > I would much rather have structures that focus on narrow responsibilities and do that well, such as an improved Map structure instead of SplObjectStorage Nothing in this RFC prevents you from having such structures. In fact, this RFC would enable more convenient handling of such structures, providing common method for requesting the programmable hash value of the object - a feature which most languages have, but PHP does not. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
