arrow syntax unnecessary and the idea that "function" is too long

Brendan Eich brendan at mozilla.com
Wed May 11 09:06:24 PDT 2011


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 <oliver at apple.com>:
>>> 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
> 



More information about the es-discuss mailing list