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?)


>

> Fundamenally, though, you have to weight each use-case by frequency. If as
> I argue var x : T, function f(a: T, b: U): V {...}, etc. annotations
> dominate the rare var typedObj = ... case, then parens or whatever is needed
> (even a separated type annotation for the whole initialiser, as in ES4) is
> worth it.
>
>
> Actually, for object literal I'd go for an equal sign (=), but that
> obviously won't fix var declarations where the colon is fine.
>
>
> We're not changing object initialiser syntax.
>

>
> Can't the guards proposal be applied to function parameters as well? Or am
> I stepping on land mines there? :) It seems like the same logic could be
> applied. In that case the equal sign is maybe even more preferable.
>
>
> What are you proposing = be used for, if not default parameter values (see
> the wiki) or assignment? No way does = make sense for type annotation.
>

I'm sorry, I did mean "=" for guard. But reading it back, you are right; it
doesn't make sense.


> But yes: type annotation (guard, contract, whateve -- not static types but
> that's not at issue) should be possible for function parameters, return
> types, local variables, let bindings, catch vars, etc.
>
> /be
>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to