- From: Maciej Stachowiak <mjs@apple.com>
- Date: Sat, 19 May 2007 14:19:45 -0700
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
Received on Saturday, 19 May 2007 14:19:45 UTC