have Objects use a new hashValue() function instead of toString() to generate the key from a non-string

RESOLVED WONTFIX

Status

()

RESOLVED WONTFIX
12 years ago
6 years ago

People

(Reporter: atec_post, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4

I want to make a map having objects as keys.

Having the following html cut:
<input type="text" name="txt" id="txt0">
<input type="text" name="txt" id="txt1">

and then script contains the following code:
var a = new Object();
var t0 = document.getElementsByName("txt")[0];
var t1 = document.getElementsByName("txt")[1];

Well, having that t0 != t1 why the following access to the map returns the same
object?
a[t0] = 1; 
a[t1] // Returns 1!


Reproducible: Always

Steps to Reproduce:
1. create two or more "input" elements with same "name" attribute and different
"id"
2. Create an empty object in javascript
3. Put to this element a dummy value (1 i.e.) with the first "input" (returned
by an getElementsByName() call) as the key.
4. Verify the wrong behaviour getting the dummy value looking to the object
with the second "input" as key
Actual Results:  
Following the details section:
a[t0] == a[t1]

Expected Results:  
a[t0] != a[t1]

Original report: bug 384167
Component: General → DOM
OS: Windows XP → All
Product: Firefox → Core
QA Contact: general → general
Hardware: PC → All
Summary: have Objects use a new hashValue() function instead of toString() to generate → have Objects use a new hashValue() function instead of toString() to generate the key from a non-string

Comment 1

12 years ago
Bug 307795 covers adding a hashCode function.  I don't think the semantics of hash[obj] can be changed (from using toString to using something like hashCode) without breaking existing code.

Updated

12 years ago
Assignee: nobody → general
Component: DOM → JavaScript Engine
QA Contact: general → general

Comment 2

12 years ago
I'd have suggested to allow for non-string keys instead - i.e. use the object itself if it isn't of a primitive type (where toString and toSource are more or less equal). As long as a hashCode can't collide with an object's string representation, the result would be the same though.

FWIW since using objects with only a generic toString result as keys doesn't really make sense (resp. is more likely to be a bug than expected behavior - I've fallen into this trap myself), we might get away with such a change - and even get more intuitive results (cf. the example of comment #0).
See http://developer.mozilla.org/es4/proposals/hashcodes.html and the several long threads on a "Dict", "Dictionary", or "Hash" native class in ES4 on the es4-discuss@mozilla.org list. This bug as stated is WONTFIX. It could be morphed into a bug requested early implementation of the right ES4 proposal, once settled (and assuming it doesn't depend on other ES4 features not yet implemented, e.g., namespaces).

/be
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.