- From: Dean Edwards <dean@edwards.name>
- Date: Sat, 26 May 2007 01:46:42 +0100
Maciej Stachowiak wrote: > On May 19, 2007, at 4:27 PM, Dean Edwards wrote: >> Maciej Stachowiak wrote: >>> On May 18, 2007, at 10:14 PM, liorean wrote: >>>> On 19/05/07, Ian Hickson <ian at hixie.ch> wrote: >>>>> The "uniqueID" thing is really working around a deficiency in JS >>>>> (inability to use objects as keys). >>>> ES4 already has something of the kind. See >>>> <uri:http://developer.mozilla.org/es4/proposals/hashcodes.html> >>>> >>>> However, that is not usable in ES3 implementations, which uniqueID is. >>> The hashcode() function is a library function and could be added to >>> ES3 implementations - I'd be willing to support it for WebKit. It >>> should be noted though that it has the same security/privacy issues >>> as uniqueID: >> >> the DOM API is language agnostic. >> This feature is too important to leave to scripting language >> implementations. > > To my knowledge, most non-JavaScript programming languages already have > facilities for hashing on object identity. This is true at least of C++, > Java, Objective-C and C; it also appears to be true of Python, Ruby, > Perl and C# as far as I can tell from the docs. What language besides > JavaScript are you concerned about? > The future looks bright but it is worth pointing out that none of the two currently available scripting languages support a hash ID. A DOM property will enable those languages (ECMAScript and VBScript) to provide backward compatibility. > Note that hascode() would be more general than uniqueID since it applies > even to non-DOM objects; it would still be needed in JavaScript even if > uniqueID was added to the DOM. > Agreed. I would use hashCode() if the language allowed it. -dean
Received on Friday, 25 May 2007 17:46:42 UTC