See also http://wiki.ecmascript.org/doku.php?id=proposals:hashcodes and especially http://wiki.ecmascript.org/doku.php?id=proposals:hashcodes#a_note_regarding_security
which date from ES4, and http://wiki.ecmascript.org/doku.php?id=strawman:encapsulated_hashcodes which needs updating. /be On May 11, 2011, at 1:06 AM, Oliver Hunt wrote: > > On May 11, 2011, at 12:55 AM, Erik Corry wrote: > >> 2011/5/10 Oliver Hunt <[email protected]>: >>> As much as I'm opposed to the idea of keyword shortening for the sake of >>> keyword shortening, the more i think about it, the less i like the arrow >>> syntax. >>> >>> I think I'd simply prefer a prefix character to the infix arrow operator, >>> mostly from a readability stand point but i have a few other issues i'll go >>> into later. When I read the examples in the wiki I simply find it >>> unpleasant and difficult, I can't put my finger on the specific reason >>> either alas :( >>> >>> I think I'd prefer the #{ expr } or #(args...){ expr } syntaxes simply to >>> ease linear reading of code. That said they seem to introduce ambiguity >>> with the Records strawman, but on the other hand i'm not too fond of >>> records or even really the tuple strawmen so maybe this isn't necessarily >>> problem. >>> >>> That said this is kind of bikeshed-y (as B said in twitter) >>> >>> Honestly these are the big issues I see in JS.current that I'd like to see >>> fixed in JS.next: >>> * Array functions (and by proxy list comprehensions) all return Arrays. I >>> think fixing this is necessary, esp. in the context of iterators existing. >>> * for in enumeration with iterators is an icky problem that needs to be >>> resolved. >>> * Generalised object subtyping >>> * Probably Mark's simple map and set APIs -- these can be implemented in >>> JS, but I suspect much more efficiently by the host vm. I thought about >>> just doing hashCode() (or whatever) but i'm not sure how v8 would do the >>> hashcodes without obviously increasing memory use. I presume it's a solved >>> problem (as Java and .NET etc can do it) but a quick Bing (i shall make >>> this a verb!!) for details didn't seem to show much useful info. >> >> We already have getters and setters in the API for an identity hash >> code. It adds an invisible property to the object (not value). This >> can cause the object to expand and change 'hidden class' in much the >> same way as would happen if someone just did o.__hashCode__ = >> Math.random(). If the hash code is not visible to the JS code then >> maps could be done in other ways than with a hash code, eg. rehashing >> when objects move. >> > I was actually thinking of object pointers from the PoV of guaranteeing > uniqueness of hashcode, which of course isn't actually a requirement > (facepalm) > >> I can see you are thinking of using the address of the object as a >> hash code. This can work, and early Java VMs did it, but there is a >> nasty gotcha: You can't leak this hash code to JS code in any way, >> because then you just defeated ASLR and leaked very valuable >> information to any attacker hoping to use buffer overflows to >> overwrite adjacent objects. You could xor all hash codes with a >> nonce, but it wouldn't be hard for the attacker to find the low bits >> of that nonce. I'm not sure whether you could recover the high bits >> somehow. > > I was aware of those issues, essential plan had been one-way unique hash from > address which as above is not necessary as you just need to have a fixed > hashcode for the object :) > >> >> Also you put an extra barrier in the way of a moving GC if you do it that >> way. > I know, which is why i was wondering how V8 did it, given that it obviously > "required" the object pointer (see above re: facepalm) > > --Oliver > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
