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
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
