Automatic semicolon insertion ...
in [JavaScript]
|
Prev: Static Class Variables and IE8 Loosely Couple Internet Explorer(LCIE)
Next: IE versions of moz transform
From: Thomas 'PointedEars' Lahn on 12 Jan 2010 14:24 Michael Haufe ("TNO") wrote: > Thomas 'PointedEars' Lahn wrote: >> Michael Haufe ("TNO") wrote: >> > Thomas 'PointedEars' Lahn wrote: >> >> It could be easily tested. >> > Do tell. >> >> Set up a loop using eval() (so as to have a new /Program/ on each call) >> and count the milliseconds it takes with and without explicitly inserted >> semicolon in the `eval' string argument. > > Do you have a test case for your numbers? Which numbers? I have made an educated guess, and told you how to confirm or disprove it. > Looking for a normalized newline token is just as easy as looking for ";" > in a tokenizer and/or a TDOP parser for example, so I'm withholding > judgment. I do not know what you are talking about. If semicolon insertion is necessary for source code to be syntactically correct, then it takes effort to do so; if not, then not. That difference should be measurable. >> And I do not agree, partially because you have yet to make a convincing >> case. > > Nor have I heard a convincing case for always using them and > everywhere just to prevent a possible ambiguity in places that seem to > me to be very easy to recognize. At this point we're just running > circles on this topic. You were the one to make the claim, you are the one to convince others that there is something to it. >> Yes, especially there it has. The warning is "Function does not always >> return a value." which is only displayed with conditional returns. The >> example you have posted does not, in general, cause a Strict warning to >> be displayed if Strict warnings are enabled. > > Here's the code: > > function foo(){ > return > true > } > > Here's the resulting warning (using Fx 3.6 RC1 + Strict Warnings): > "useless expression" Iceweasel 3.5.7 does not display such a warning. Either that is a new feature of Gecko/TraceMonkey 1.9.2 or Firebug 1.5.0b9 interferes. PointedEars -- Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript. -- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk>
From: "Michael Haufe ("TNO")" on 12 Jan 2010 16:07 On Jan 12, 1:24 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > Which numbers? I have made an educated guess, and told you how to confirm > or disprove it. The burden of proof is not on me to validate _your_ claim one way or another. > > Looking for a normalized newline token is just as easy as looking for ";" > > in a tokenizer and/or a TDOP parser for example, so I'm withholding > > judgment. > > I do not know what you are talking about. If semicolon insertion is > necessary for source code to be syntactically correct, then it takes effort > to do so; if not, then not. That difference should be measurable. Once you finish creating your test(s), we'll know for sure. Either way, the results are irrelevant to the discussion. > You were the one to make the claim, you are the one to convince others that > there is something to it. Then you didn't comprehend what I wrote. Try reading again.
From: Andrew Poulos on 12 Jan 2010 16:46 On 13/01/2010 8:07 AM, Michael Haufe ("TNO") wrote: > On Jan 12, 1:24 pm, Thomas 'PointedEars' Lahn<PointedE...(a)web.de> > wrote: >> Which numbers? I have made an educated guess, and told you how to confirm >> or disprove it. > > The burden of proof is not on me to validate _your_ claim one way or > another. > >>> Looking for a normalized newline token is just as easy as looking for ";" >>> in a tokenizer and/or a TDOP parser for example, so I'm withholding >>> judgment. >> >> I do not know what you are talking about. If semicolon insertion is >> necessary for source code to be syntactically correct, then it takes effort >> to do so; if not, then not. That difference should be measurable. > > Once you finish creating your test(s), we'll know for sure. Either > way, the results are irrelevant to the discussion. > >> You were the one to make the claim, you are the one to convince others that >> there is something to it. > > Then you didn't comprehend what I wrote. Try reading again. I really enjoy how the argument becomes about winning or losing (the perceived rhetoric challenge). Andrew Poulos
From: Hans-Georg Michna on 12 Jan 2010 17:58 On Mon, 11 Jan 2010 17:14:44 -0800 (PST), Michael Haufe ("TNO") wrote: >On Jan 11, 3:59�pm, Hans-Georg Michna <hans- >georgNoEmailPle...(a)michna.com> wrote: >> By the way, I have had a recent case where semicolon insertion >> was over-eager in Internet Explorer 8. I had split a lengthy >> return statement into several lines, and IE8 inserted a >> semicolon where I had not intended to be one. >I would consider an overly long return statement a code smell anyway. >Its simple enough to wrap the statement with parentheses or break the >line(s) along operators instead of names. Sure, that was not difficult to solve. I merely removed a line break. But that means I'm becoming the slave of the computer, rather than the other way around. More interestingly, it means that automatic semicolon insertion is a "feature" I would instantly kill, if I could. Hans-Georg
From: Thomas 'PointedEars' Lahn on 12 Jan 2010 18:41
Michael Haufe ("TNO") wrote: > Thomas 'PointedEars' Lahn wrote: >> Which numbers? I have made an educated guess, and told you how to >> confirm or disprove it. > > The burden of proof is not on me to validate _your_ claim one way or > another. AISB: I have _not_ made a claim, so I do _not_ have to prove anything here. I have said "it stands to reason that inserting semicolons where otherwise automatically inserted potentially increases the overall efficiency of code", which translates to "it is reasonable to assume that ...", while explaining why I think so. I have kindly told you, upon your request, how I think that assumption could be confirmed or disproved. If you want to confirm or disprove it, or if you want to present more arguments in favor or against that position, be my guest. If not, then not. I won't mind. PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann |