W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2007

[whatwg] Scripting Tweaks

From: Maciej Stachowiak <mjs@apple.com>
Date: Sat, 19 May 2007 18:01:31 -0700
Message-ID: <97A8826D-4A0E-4EC2-A932-8C00A3EF073A@apple.com>

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). I think that's where it  
>>>> should be
>>>> addressed. The uniqueID idea has a number of rather unique  
>>>> implementation
>>>> difficulties. The obvious implementations have security and privacy
>>>> implementations; the solutions to those tend to be expensive  
>>>> either in RAM
>>>> or CPU. I recommend bringing this to the attention of the ES4  
>>>> group.
>>>
>>> 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:
>
> This is all relevant of course but 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?

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.

Regards,
Maciej
Received on Saturday, 19 May 2007 18:01:31 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:55 UTC