On Nov 22, 2010, at 1:03 AM, Peter van der Zee wrote:
> On Mon, Nov 22, 2010 at 9:43 AM, Brendan Eich <bren...@mozilla.com> wrote:
> On Nov 22, 2010, at 12:37 AM, Peter van der Zee wrote:
>
>> On Mon, Nov 22, 2010 at 6:54 AM, Brendan Eich <bren...@mozilla.com> wrote:
>>
>> The ML-ish solution, which is forward compatible, is to parenthesize:
>>
>> let typedObj = { (prop1:type1): value1, (prop2:type2): value2, ... };
>>
>> The parentheses hurt too, but only this case. And it still may win to
>> annotate the entire ObjectLiteral sometimes, which would avoid (or move to
>> one common guard-type definition) the property-wise annotation overhead.
>> Comments?
>>
>> I wouldn't want to introduce forced parens for the sake of disambiguation
>> for the coder. I'd rather go with ::, # or @ ...
>
> Those are not all equally good, and you're again sacrificing the common case
> (especially with ::) where there's no need to parenthesize, for the uncommon
> case of property-wise type annotation in an object initialiser.
>
> Actually, one can use : just fine in an initialiser provided one or two
> colons are required per property initialiser. There's no need for :: or
> anything else except to avoid a confusing re-use of colon. Which is an issue,
> but :: doesn't exactly address it!
>
>
> As you noted yourself in the other thread, if iterators take on the syntax of
> `for (var x : y : z)`, the single colon for guards would introduce ambiguity.
> (And I believe "::" could fix that?)
First, I did not argue that there was a formal grammar ambiguity. There may not
be, but it still is ugly and confusing.
Second, you're arguing backwards -- we do not have for (x : z) today, it is not
obvious we should add it to the language, so it does not follow that we must
use :: for type annotations. The precedent for : as type annotation punctuator
is stronger than the precedent for :: in the same role; meanwhile, from E4X and
AS3 and other old-ES4 offshoots, we have :: for namespace qualification (C++
has that too). So :: is just wrong all around.
Before reaching in a reactive way for @, let's slow down and consider what got
us here: over-eager bikeshedding of : instead of "in" to try to split for-in
into two loops, to make programmers prejudge whether they want enumeration or
something potentially meta-programmable (but not necessarily -- we did not
decide that for (x : z) fails if z is not a proxy with an iterate trap, and
that doesn't make much sense).
So as dherman pointed out, we're really just trying to replace for-in with
for-: as the new for-in. But if the syntax is ugly and confusion, if not
ambiguous, and if the new form won't work in old browsers anyway, what good are
we doing? Defending against someone porting or mixing JS code into Harmony
context and having a for-in loop that expects string keys fail because it got
Fibonacci numbers?
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
