Rationalizing ASI (was: simple shorter function syntax)
Mark S. Miller
erights at google.com
Mon Jul 26 14:11:58 PDT 2010
I'm proposing that the same opt-in that makes function call a restricted
production also turns off semicolon insertion, making that code into a
static syntax error. For those cases where the language can't reliably tell
what I mean, I don't want it to guess.
On Mon, Jul 26, 2010 at 2:02 PM, Waldemar Horwat <waldemar at google.com>wrote:
> Maciej Stachowiak wrote:
>
>> On Jul 25, 2010, at 5:06 PM, Brendan Eich wrote:
>>
>>> Mark's restricted production idea is on target, if we think it's worth
>>> doing.
>>>
>>
>> At least in C or C++, I've seen code like this:
>>
>>
>> veryLongObjectName.someOtherVeryVeryLongObjectName.ridiculouslyLongFunctionName
>> (longArgument1, longArgument2, longArgument3, longArgument4,
>> longArgument5);
>>
>> If I understand correctly, Mark's proposal would make that a syntax error
>> in JavaScript. I'm not sure offhand if JavaScript programmers write in this
>> style, or would find the loss annoying. Of course, you could always write
>> this as a single very long line, or make sure that at least the open paren
>> is on the first line, but programmers can be picky about questions of style
>> like this.
>>
>
> If you made function invocation a restricted production then semicolon
> insertion would turn the above code into:
>
>
>
> veryLongObjectName.someOtherVeryVeryLongObjectName.ridiculouslyLongFunctionName;
> (longArgument1, longArgument2, longArgument3, longArgument4,
> longArgument5);
>
> Waldemar
>
--
Cheers,
--MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100726/cb89769f/attachment.html>
More information about the es-discuss
mailing list