Along the lines of improving JS towards a version 1.6... Most OO languages has a way to get a unique hash code for an object. JavaScript does not. Python: obj.__hash__() Java: obj.hashCode() http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html#hashCode() .NET: obj.GetHashCode() http://msdn.microsoft.com/library/en-us/cpref/html/frlrfsystemobjectclassgethashcodetopic.asp

hashCode values can be reused after objects are GCed, so I imagine it's easy to introduce subtle bugs by using hashCode. I'd rather see support for weak-key hash tables instead of support for hashCode.

Please see http://wiki.ecmascript.org/doku.php?id=proposals:hashcodes which may end up in ES3.1 if I act quickly enough. Note the spelling: Java nerded out with hashCode, but hashcode is a single-word neologism, so no camelCaps. Jesse, hashcodes can collide in any event. Weak-keyed maps require more work from the GC in general (if your GC does global mark/sweep, hashcode does not have to deal with copying, but weak-keyed-maps require weak references or ephemerons). /be

(In reply to comment #3) > Jesse, hashcodes can collide in any event. Weak-keyed maps require more work > from the GC in general (if your GC does global mark/sweep, hashcode does not > have to deal with copying, but weak-keyed-maps require weak references or > ephemerons). On the other hand for any GC that tries to compact things (which is even feasible to implement for SM), weak-keyed-maps would be easy to implement than the hashcode.

Another argument against hashcode is security. If hashcode is implemented through returning the address of the object, then it would be much easier to exploit a few GC hazards that were found in past since the script can learn the addresses of its objects. To prevent that information leakage one would need to apply a cryptographically strong one-way function to the address. But then weak-hashing may be simpler to implement even when the GC does not move things.

(In reply to comment #3) > Weak-keyed maps require more work from the GC in general hashcode() cannot be used to implement the weak-hash maps, so it only natural that weak-keyd maps require more work. Ordinary hash maps are transparent to the GC.

(In reply to comment #5) > Another argument against hashcode is security. If hashcode is implemented > through returning the address of the object, then it would be much easier to > exploit a few GC hazards that were found in past since the script can learn the > addresses of its objects. That is an argument against bad security design of hashcode, not against providing hashcodes. (Could hashcode be a static or top-level method, such that it could be used on primitives and null?)

(In reply to comment #5) > Another argument against hashcode is security. If hashcode is implemented > through returning the address of the object, ... Please read the ES4 proposal, the informative parts too. (In reply to comment #7) > That is an argument against bad security design of hashcode, not against > providing hashcodes. Right. > (Could hashcode be a static or top-level method, such that it could be used on > primitives and null?) Yes, ES4 proposed it as a function, not a method. Please read graydon's fine writing! This bug as summarized is not going to be fixed. The only wrinkle now is the loss of namespaces, so instead of intrinsic::hashcode, or __ES4__::hashcode, it's likely to be Object.hashcode (putting "static methods" on Object is least likely to break existing code, if you have to choose among adding methods to prototypes, adding new globals, and adding static methods). Re-summarizing but we need a spec for Object.identical to go with Object.hashcode (identity is not the strict equality operator). Volunteers? /be

New features to JavaScript should now be proposed to TC39 [1] before being implemented in SpiderMonkey, therefore closing as Invalid. [1] https://github.com/tc39/proposals/blob/master/CONTRIBUTING.md