[whatwg] Scripting Tweaks

[Maciej Stachowiak]

On May 18, 2007, at 10:14 PM, liorean wrote:

> On 19/05/07, Ian Hickson <ian at hixie.ch> wrote:
>>
>>   for (var i in elements) {
>>     if (!elements[i].processed) {
>>       process(elements[i]);
>>       elements[i].processed = true;
>>     }
>>   }
>>   for (var i in elements)
>>     delete elements[i].processed;
>>
>> 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:

"The function intrinsic::hashcode should not return pointer values  
cast to integers:

	• Exposing memory locations of objects may make security  
vulnerabilities in the host environment significantly worse.  
Implementations – in particular those which read network input –  
should return numbers unrelated to memory addresses if possible, or at  
least use memory addresses subject to some cryptographically strong  
one-way transformation, or sequence numbers, cookies, etc."

It should be noted that "sequence numbers" are arguably a privacy  
violation (the site can tell about how long you have been browsing). A  
cryptographically strong transformation of memory addresses  
unfortunately clashes with the goal of good performance (OK, maybe not  
seeding the hash computation with a random value per browser session  
would be cryptographically strong but could still be fast to compute  
and meet the requirements for good hash functions.)

However, since hashcodes don't have to be globally and permanently  
unique, if you use a hash function to implement them at least you  
don't have to store them in a global table to avoid collisions.

All told, I like hashcode() better than uniqueID.

> Besides, the problem is solvable without polluting the objects by
> adding property through using one object for storing processed
> elements and one object for the full set of elements. Then you can use
> something like
>
>   processed_elements[key]=all_elements[key];
>
> for storing that an element is processed,
>
>  delete processed_elements[key];
>
> to remove an element from the processed elements list, and something  
> like
>
>   for(key in all_elements)
>       if(!(processed_elements.hasOwnProperty(key)))
>           process(key);
>
> to iterate through the unprocessed elements.

Good point, you can store a parallel array for processed objects and  
still get O(1) access.

Regards,
Maciej