>> 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).
Just because you say it doesn't affect it doesn't mean it doesn't. I think it would be quite silly to support storing hashes and/or storing objects and to me that blocks the latter since you are proposing the former. > 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. Programmable hashes of objects should be external to the object anyway because eventually someone wants to store the same object in a different way in two different structures. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
