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

Oliver Hunt oliver at apple.com
Tue May 10 12:49:09 PDT 2011


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.

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



More information about the es-discuss mailing list