On Mon, Apr 18, 2011 at 22:52, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> On 4/18/11, Claus Reinke <claus.rei...@talk21.com> wrote:
>>> The only places where semicolons are ever used in the Node.js package
>>> manager are in the 'for' loops headers and at the *beginning* of the lines
>>> that would be interpreted incorrectly because of the lack of the semicolon
>>> at the end of the *previous* line - for example see:
>>> https://github.com/isaacs/npm/blob/master/lib/utils/read-json.js#L320-L336
>>>
>>> There are no semicolons at the end of lines *at all*.
npm author here.
> If you can think it, there is a porn for it.
It's not syntax porn, I assure you. This style is more easily
scanned. The important tokens are along the left edge, which forms a
straight line with logical and orderly breaks, and those tokens are
not overused, so their presence or absence is very noticeable. The
right-edge is jagged, and when every line has a ";", the brain tends
to filter out their presence, making it hard to notice their absence.
Maybe your brain doesn't have the same pattern-matching style as mine,
of course. But, willy nilly, I have the brain I do, so I made npm
look the way it does, so that it's easier for me to avoid and find
bugs with a minimum of friction.
This is all to say, relying on ASI is (sometimes) a sane and pragmatic
decision, and not difference for difference's sake.
> Restricted productions are the most benign cases. How ASI changes
> program behavior WRT unrestricted productions is bigger problem.
Can you provide examples of the sort of unrestricted productions
you're referring to, where unexpected "semicolon insertion" changes
program behavior? In my experience, it is the *lack* of ASI that
usually causes problems with unrestricted productions.
>> In brief, there is no way simply to take away ASI, and any
>> attempt to introduce a less troublesome variant of ASI will
>> have to offer a way to deal with existing code.
>>
> The number of developers advocating ASI as a "best practice" can't be
> stopped either.
Developers using ASI and advocating its use should be taken as a
datapoint for our discussion of the language, don't you think?
Regardless of whether or not you agree with them, breaking their model
drastically will only result in a lower adoption of
Harmony/es-next/opt-in-whatever.
>> As a coder, you really don't want to add semicolons to
>> avoid ASI traps, as in line 232 of your example
>>
>> ;["dependencies", "devDependencies"].forEach(function (d) {
Yes. I've never started a line with [ with the intent of it being a
property access. I do sometimes start a new line with ( for a
function call, if the list of arguments is long, but it's a practice
I'd gladly change in exchange for saner statement ending rules.
> Why do I want to have to worry about what might have been omitted? No,
> I want to worry about what the code says. I consider a statement
> terminator to be just that; when I read it, I see end of statement.
> don't want to read beginning of statement preceeded by empty
> statement.
In that case, what the code "says" is exactly the same, whether the
semicolon is on the next line or not.
There is nothing fundamental or essential about ; being a "terminator"
rather than a "separator". In fact, that's what it actually is in
EcmaScript - a statement separator. (Likewise in sh/bash/zsh, Perl,
Ruby, Erlang, and many others.) In Java, PHP, C, and C++, it is a
terminator. This isn't c-devel or java-devel, it's es-devel.
The "use superasi" pragma would effectively make [ and ( treated a bit
like restricted productions, in that a line break before them *always*
terminates the statement. I'm not sold on this idea, necessarily, but
I think it's important to consider options other than how to remove
ASI from the language.
> Exactly. Multiline comments add extra problems.
How so?
--i
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
