On Jun 20, 2011, at 12:40 PM, Axel Rauschmayer wrote:

>> Quasi-literals rule, and `` is the right quoting system given the characters 
>> left that can be easily typed and that don't ding readability.
> 
> Yes, I love them and hope that assignment via ${=x} makes it into ES.next, 
> because that’ll enable us to do all kinds of matching.

Me too.


>> We have <| but it is a bit contentious. No one has topped it, though, and a 
>> keyword instead seems to lose on both restricted-production and 
>> no-better-word-than-<| grounds.
> 
> I like that one, it’s very visual; I find it more descriptive than the 
> keyword "proto".

Great.


>> Some find -> and => cryptic, but it's hard to say the only alternative is to 
>> stick to eight-letter 'function'. ('lambda' is not reserved and can't be 
>> used without breaking compatibility; and it's six letters.)
>> 
>> Some find block-lambdas with their Ruby- (and to a lesser extend Smalltalk-) 
>> inspired {||...} bracketing cryptic.
> 
> - Pro block-lambdas: A new construct that can be used in places where dynamic 
> |this| (that normal functions are always going to have) would be a burden.

And for other purposes, such as block-like "bodies" of Array forEach, etc. 
methods.


> - Pro arrows: little semantic change.

No semantic change, I claim. What differs apart from syntax?

There's a dependency on completion reform, but that is a separate semantic 
change (already in Harmony).


> With the shorthand for methods in object literals, there is the question 
> whether dynamic |this| is ever needed.

This does not make sense.

Object literals used for prototypes have methods but those methods must use 
dynamic |this| because the calls use individual instances as their reference 
bases, not the prototype.


> But if we need both dynamic and lexical |this|, then the arrows are nice in 
> that they look similar, but are still different.

Dynamic |this| is an essential part of the prototypal pattern.


> - Pro ƒ: short, syntactically very similar to current semantics *and* syntax.

The florin works no better than Greek lower-case lambda. Both are already legal 
ES3-5.1 Identifiers and cannot be retasked as keywords, especially not with the 
name of the function in a function expression optional.


> var obj = theProtoObj <| {.seal,
>    @const
>    konst: f(),

Too verbose, and requiring it to be on its own line compounds the problem by 
taking too much vertical space. Plus, we have no decorator proposal yet. Plus 
on top, decorators are for metadata that may be erased, or that at least must 
be optional. Non-writability in ES5 and up is not optional or erasable.


> - Does enumerability ever matter?

It sure does. Consider how PrototypeJS extends standard prototypes. See

http://blip.tv/jsconf/jsconf2011-andrew-dupont-everything-is-permitted-extending-built-ins-5211542

/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to