On Nov 22, 2010, at 3:08 PM, Waldemar Horwat wrote:
> On 11/22/10 10:13, Brendan Eich wrote:
>>> { foo : G : 33 }
>>
>> 0. let typedObj = { foo : 33 } : { foo : G }; // a la ES4
>>
>> 1. let typedObj = { foo :: G : 33 }; // the guards strawman
>>
>> 2. let typedObj = { (foo : G) : 33 }; // the ML-ish way
>>
>> 3. let typedObj = { foo @ G : 33 }; // funny cartoon chars
>
> Good list. Out of those five, the only one I'd find compelling would be the
> first:
>
> { foo : G : 33 }
>
> Alternatives 0, 1, and 3 have the problems that were already well-stated. 2
> has strange placement of parentheses.
Parens do hurt, I always thought so -- I find 2 the least evil of 0-3 though.
> If we're brainstorming, I'd throw out an alternative for the object
> initializer syntax:
>
> {name: value} // What we have now, for compatibility
> {name = value} // Identical behavior to {name: value}
> {name: type = value} // Adding a type annotation
Isn't the last ambiguous with legal JS today (well, with const, but that's not
important AFAICT):
js> const T = {}
js> function f(x) { return {p: T = x}; }
js> o = f(42)
({p:42})
ES5 strict mode is the basis for Harmony, so the assignment would be an early
error, but are guard bindings required to be const?
> If we're looking at other ASCII characters for type annotations, a few other
> characters such as the backtick might be an option:
>
> {name`type: value}
> {name!type: value}
> {name%type: value}
> {name~type: value}
Do you mean only for initialisers, or for all declarations. In a var x!T = v;
example, he unary operator (! or ~) seems problematic here in light of ASI
unless the production is restricted before the operator.
% as "mod" has some metaphorical appeal but really, these all seem like Perlish
line noise compared to colon.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
