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

Erik Corry erik.corry at gmail.com
Wed May 11 00:55:39 PDT 2011


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 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.

Also you put an extra barrier in the way of a moving GC if you do it that way.


>
> --Oliver
>
> On May 9, 2011, at 6:04 PM, Brendan Eich wrote:
>
>> On May 7, 2011, at 1:37 AM, Jorge wrote:
>>
>>> But if I wanted a shorter syntax, I would no doubt choose ruby blocks' syntax, it's even shorter yet and it's familiar already to millions of programmers.
>>
>> Ruby and Smalltalk before it had blocks for most of their usable lives. JS does not. Having break, continue, return, this, arguments, and perhaps other features of JS change meaning in a block to refer to aspects of the outer function's activation (if still active) is a big change. It adds new runtime error cases. It's certainly not simpler than shorter function syntax.
>>
>> Not all JS hackers are Rubyists.
>>
>> /be
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>


More information about the es-discuss mailing list