On Sun, Jul 25, 2010 at 11:36 AM, Brendan Eich <bren...@mozilla.com> wrote:
> On Jul 25, 2010, at 10:52 AM, Mark S. Miller wrote:
>
> The problem is that as long as ASI exists, one will often see working code
> such as this, since it does usually work. This training of the eye is a kind
> of habituation, and in this case it is insidious because it desensitizes the
> programmer from a pattern that *should* look malformed but doesn't.
>
> Ok, I'll grant you ASI desensitization is a factor in human readers missing
> this kind of bug.
>
> In the absence of ASI, such code would never normally appear in running
> code.
>
> Come on! "Never" ("normally" doesn't count, it's just hedging in a way that
> tends to assume the conclusion) must mean that if only we didn't suffer from
> ASI-based desensitization to missing semicolons, we would have
> perfect manual semicolon insertion and perfect code auditing and testing.
> But utopia is not an option.
>
> This hazard is insidious because testing may fail to uncover it, since
> tests have bugs too, test coverage is never perfect, and what's more, if the
> function expression itself returns a similar enough function, the caller of
> the stored method might not notice any malfunction.
>
> So let's agree on "less often" -- not "never".
>
Sure.
> When it does appear in running code, that should alert the programmer that
> their program violates their intention and needs to be fixed.
>
> That's nice, but "should" is not good enough. Empirically, it doesn't work
> that way. I'm not just going by my experience, but by the jibbering page,
> the bug reports I've seen, the Dojo guys who do use semicolons still having
> to ward off this hazard with a leading ; in each source file.
>
> Let's not go in circles. I claim:
>
> * The horses are long gone from the barn.
> * The mistake is easy to overlook even for JS coders who do use semicolons.
> * The trade-off of banning ASI rule 1 first bullet to reduce
> desensitization and eventually reduce the incidence of this kind of bug is
> not a clear win, vs. migration tax into Harmony and usability problems even
> writing fresh code.
>
> In order to reliably remove this hazard, we would need to ban statements
> from starting with '('. Perhaps we should consider doing so.
>
The problem there is the common module pattern
(function(){
...
})();
Although less common, defining an anonymous object literal and using it
inline is perfectly sensible:
({
... // includes methods mentioning "this"
}).foo(...);
Perhaps, under the hypothetical opt-in, we should also consider
CallExpression a restricted production?
CallExpression : ...
CallExpression [no newline here] Arguments
This would more reliably catch the above hazards without breaking pleasant
legitimate uses.
>
> /be
>
>
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
