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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss