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
