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 };
I'd expect that
o = { a : b = 5 }
Was legal now, setting both o.a and b to 5. Not at a shell, is there an
exception in the grammar for assignment expressions in the value position?
{ a = 5 : T } might work, though.
Mike
On Nov 22, 2010 6:09 PM, Waldemar Horwat walde...@google.com wrote:
On
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 };
On 11/22/10 15:16, Brendan Eich wrote:
{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):
Yeah, you're right. This won't work.
Waldemar
___
I think there is too much fear of changing the semantics of for-in. Its
semantics is already rather fuzzy. Allowing meta-programmability of for-in
(instead of creating a new for-:) syntax doesn't create any additional
surprises or hazards for JS programmers.
1. We have already agreed on an
On Nov 22, 2010, at 4:07 PM, Andreas Gal wrote:
Executive summary: iterate() is equivalent to enumerate(), both should work
with for-in. We already agreed to accept enumerate, forcing iterate() into
its own syntax is arbitrary. We can discuss sacrificing future-proofness and
stringify
I somehow suspect stringifying the iterator next() return value from for-in
machinery will not placate folks who want for-in not to be metaprogrammable.
Nor would it work -- you wouldn't be able to get the values() or properties()
iteration behavior, for example. It would be the worst of all
7 matches
Mail list logo
