Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.javascript > #8282 > unrolled thread
| Started by | " Cal Who" <CalWhoNOSPAM@roadrunner.com> |
|---|---|
| First post | 2011-11-13 09:51 -0500 |
| Last post | 2011-11-14 15:05 +0000 |
| Articles | 8 on this page of 48 — 12 participants |
Back to article view | Back to comp.lang.javascript
Difference between findPos("divThis") and findPos(divThis) " Cal Who" <CalWhoNOSPAM@roadrunner.com> - 2011-11-13 09:51 -0500
Re: Difference between findPos("divThis") and findPos(divThis) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-13 18:25 +0100
Re: Difference between findPos("divThis") and findPos(divThis) " Cal Who" <CalWhoNOSPAM@roadrunner.com> - 2011-11-13 13:58 -0500
Re: Difference between findPos("divThis") and findPos(divThis) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-13 20:26 +0100
Re: Difference between findPos("divThis") and findPos(divThis) " Cal Who" <CalWhoNOSPAM@roadrunner.com> - 2011-11-13 15:04 -0500
Re: Difference between findPos("divThis") and findPos(divThis) "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-13 18:55 -0200
Re: Difference between findPos("divThis") and findPos(divThis) "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-13 18:59 -0200
Re: Difference between findPos("divThis") and findPos(divThis) " Cal Who" <CalWhoNOSPAM@roadrunner.com> - 2011-11-13 17:10 -0500
Re: Difference between findPos("divThis") and findPos(divThis) "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-13 20:49 -0200
Re: Difference between findPos("divThis") and findPos(divThis) " Cal Who" <CalWhoNOSPAM@roadrunner.com> - 2011-11-13 20:00 -0500
Re: Difference between findPos("divThis") and findPos(divThis) Denis McMahon <denismfmcmahon@gmail.com> - 2011-11-14 02:37 +0000
Re: Difference between findPos("divThis") and findPos(divThis) "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-14 03:14 -0200
Re: Difference between findPos("divThis") and findPos(divThis) Denis McMahon <denismfmcmahon@gmail.com> - 2011-11-14 14:03 +0000
Re: Difference between findPos("divThis") and findPos(divThis) "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-14 14:14 -0200
Re: Difference between findPos("divThis") and findPos(divThis) Denis McMahon <denismfmcmahon@gmail.com> - 2011-11-14 18:31 +0000
Re: Difference between findPos("divThis") and findPos(divThis) "Evertjan." <exjxw.hannivoort@interxnl.net> - 2011-11-14 18:36 +0000
Re: Difference between findPos("divThis") and findPos(divThis) Denis McMahon <denismfmcmahon@gmail.com> - 2011-11-15 00:18 +0000
Re: Difference between findPos("divThis") and findPos(divThis) Scott Sauyet <scott.sauyet@gmail.com> - 2011-11-14 10:54 -0800
Re: Difference between findPos("divThis") and findPos(divThis) "Richard Cornford" <Richard@litotes.demon.co.uk> - 2011-11-15 01:23 +0000
Re: Difference between findPos("divThis") and findPos(divThis) Scott Sauyet <scott.sauyet@gmail.com> - 2011-11-16 06:04 -0800
Re: Difference between findPos("divThis") and findPos(divThis) Frobernik <nospam@nospam.com> - 2011-11-17 22:06 +0000
Re: Difference between findPos("divThis") and findPos(divThis) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-17 23:54 +0100
Re: Difference between findPos("divThis") and findPos(divThis) Frobernik <nospam@nospam.com> - 2011-11-18 09:33 +0000
Function arguments vs. local variables (was: Difference between findPos("divThis") and findPos(divThis)) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-19 16:05 +0100
Re: Function arguments vs. local variables Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-19 18:17 +0100
Re: Function arguments vs. local variables Frobernik <nospam@nospam.com> - 2011-11-21 20:01 +0000
Re: Function arguments vs. local variables Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-22 12:50 +0100
Re: Difference between findPos("divThis") and findPos(divThis) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-14 15:04 +0100
Re: Difference between findPos("divThis") and findPos(divThis) John G Harris <john@nospam.demon.co.uk> - 2011-11-14 15:13 +0000
Re: Difference between findPos("divThis") and findPos(divThis) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-14 18:27 +0100
Re: Difference between findPos("divThis") and findPos(divThis) Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2011-11-14 17:52 +0100
Re: Difference between findPos("divThis") and findPos(divThis) "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-14 15:07 -0200
Re: Difference between findPos("divThis") and findPos(divThis) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-14 18:19 +0100
Re: Difference between findPos("divThis") and findPos(divThis) "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-14 15:44 -0200
Re: Difference between findPos("divThis") and findPos(divThis) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-14 19:01 +0100
Re: Difference between findPos("divThis") and findPos(divThis) "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-14 16:42 -0200
Re: Difference between findPos("divThis") and findPos(divThis) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-14 19:53 +0100
Re: Difference between findPos("divThis") and findPos(divThis) Richard Cornford <Richard@litotes.demon.co.uk> - 2011-11-14 09:18 -0800
Re: Difference between findPos("divThis") and findPos(divThis) "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-14 16:22 -0200
Re: Difference between findPos("divThis") and findPos(divThis) Denis McMahon <denismfmcmahon@gmail.com> - 2011-11-14 18:38 +0000
Re: Difference between findPos("divThis") and findPos(divThis) Gene Wirchenko <genew@ocis.net> - 2011-11-14 12:12 -0800
Re: Difference between findPos("divThis") and findPos(divThis) Gene Wirchenko <genew@ocis.net> - 2011-11-14 12:00 -0800
Re: Difference between findPos("divThis") and findPos(divThis) " Cal Who" <CalWhoNOSPAM@roadrunner.com> - 2011-11-14 08:48 -0500
Re: Difference between findPos("divThis") and findPos(divThis) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-14 13:15 +0100
Re: Difference between findPos("divThis") and findPos(divThis) "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-14 13:03 -0200
Re: Difference between findPos("divThis") and findPos(divThis) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-14 17:24 +0100
Re: Difference between findPos("divThis") and findPos(divThis) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-14 13:00 +0100
Re: Difference between findPos("divThis") and findPos(divThis) John G Harris <john@nospam.demon.co.uk> - 2011-11-14 15:05 +0000
Page 3 of 3 — ← Prev page 1 2 [3]
| From | Gene Wirchenko <genew@ocis.net> |
|---|---|
| Date | 2011-11-14 12:12 -0800 |
| Message-ID | <04t2c71l61pupn80faamh803qcnke0maie@4ax.com> |
| In reply to | #8326 |
On Mon, 14 Nov 2011 09:18:09 -0800 (PST), Richard Cornford
<Richard@litotes.demon.co.uk> wrote:
>On Nov 14, 5:14 am, J.R. wrote:
[snip]
>> The advantages of using the Single var Pattern at the top of your
>> functions are:
[snip]
>> - Helps you remember to declare variables and therefore minimize
>> globals;
>
>This is not an advantage over multiple consecutive variable
>declaration statements at the top of that same function.
In fact, it might be a disadvantage! Consider:
var a="somthing",
b="another"
c="YA"
which is correct but misleading code. c is not declared here. What
was intended was:
var a="somthing",
b="another",
c="YA"
(added a comma to the second line)
>> - only one var statement means less code to type and a reduction
>> in the file size.
>
>So it would be (at best) the opportunity to save half a dozen bytes
>that is the only factor left that could justify the "antipattern"
>assertion, on the grounds of the alternatives being
>counterproductive. I won't be buying that argument as this would be
>neutralised by zipping the resource to be sent to the client, while
>the potential added obscurity in the source code looks too negative to
>me.
I would rather type var a few more times and feel safer about my
code. See my example above. Sir Hoare said it well:
"I was eventually persuaded of the need to design programming
notations so as to maximize the number of errors which cannot be made,
or if made, can be reliably detected at compile time. Perhaps this
would make the text of programs longer. Never mind! Wouldn't you be
delighted if your Fairy Godmother offered to wave her wand over your
program to remove all its errors and only made the condition that you
should write out and key in your whole program three times!"
[snip]
>> There are patterns in any programming language usually adopted
>> by programmers as "best coding practices". And it happens to
>> other fields of study too. See
>> <http://en.wikipedia.org/wiki/Best_Coding_Practices>
>
>Maybe, but a high proportion of "best practices" that have been
>proposed for javascript have been pretty much BS. Misunderstandings/
>miscomprehensions abound, but the people looking for rules that will
>supposedly help them cannot easily tell. I always recommend that no
>"best practice" should be taken seriously unless it is presented
>alongside a reasoned justification, and that that justification stands
>up to critical scrutiny. For anything that really is a "best practice"
>that should be an achievable requirement.
Quite.
[snip]
Sincerely,
Gene Wirchenko
[toc] | [prev] | [next] | [standalone]
| From | Gene Wirchenko <genew@ocis.net> |
|---|---|
| Date | 2011-11-14 12:00 -0800 |
| Message-ID | <jms2c75jr3srjs9ck1bsiv41ko9rgebqrn@4ax.com> |
| In reply to | #8304 |
On Mon, 14 Nov 2011 03:14:20 -0200, "J.R." <groups_jr-1@yahoo.com.br>
wrote:
>On 14/11/2011 00:37, Denis McMahon wrote:
>> On Sun, 13 Nov 2011 20:49:25 -0200, J.R. wrote:
[snip]
>>> You must not use multiple var statements such as:
>>> var el;
>>> var h = ...;
>>> var z;
>>
>> Rubbish.
>>
>> You can use as many var statements as you like. Nothing in the standards
>> or the implementation prevents this, so "must not" is incorrect.
>
>"must not" was exaggerated on purpose, because using many var statements
>is an antipattern in JavaScript.
Exaggerating to make a point is an anti-pattern of its own. It
means that anyone reading what you write can not simply take it at
face value, but now has to figure out whether the meaning to use is
the literal one or a weaker form of it.
[snip]
Sincerely,
Gene Wirchenko
[toc] | [prev] | [next] | [standalone]
| From | " Cal Who" <CalWhoNOSPAM@roadrunner.com> |
|---|---|
| Date | 2011-11-14 08:48 -0500 |
| Message-ID | <j9r670$2df$1@dont-email.me> |
| In reply to | #8300 |
"Denis McMahon" <denismfmcmahon@gmail.com> wrote in message news:4ec07ef1$0$28711$a8266bb1@newsreader.readnews.com... > On Sun, 13 Nov 2011 20:49:25 -0200, J.R. wrote: > >> it is one of the JavaScript best practices to declare all of the >> variables used in a function at the top of the function body. You may >> have many variables separated by commas, e.g > >> var el = ..., >> h = ..., >> w = ..., >> i, j, len, ..., z; > >> You must not use multiple var statements such as: >> var el; >> var h = ...; >> var z; > > Rubbish. > > You can use as many var statements as you like. Nothing in the standards > or the implementation prevents this, so "must not" is incorrect. > > Some people think all variables should be declared in a single statement. > Some people use a different statement for each type of variable, where > type is the sort of data that it will be used to hold (array, string, > integer, float, object etc). > Some people just use one variable per var. > > These are all permitted by the various standards, and they all work. > There is no reason that you "must" or "must not" do any of these. > > Also, "best practice" is invariably "in the opinion of the author of the > website / book / blog / whatever" that said example of best practice > appears in. As a matter of interest, what's your reference for "best > practice"? If I write a book or start a blog called "Javascript - Best > Practice" does that make it true? > > Rgds > > Denis McMahon Thanks
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2011-11-14 13:15 +0100 |
| Message-ID | <8932764.SEqChMirdb@PointedEars.de> |
| In reply to | #8296 |
J.R. wrote: > On 13/11/2011 20:10, Cal Who wrote: >>> >>> var el = (typeof obj == 'string') ? document.getElementById(obj) : >>> obj, >>> w = el.offsetWidth, // , instead of ; >>> h = el.offsetHeight; >>> >> That's neat. >> >> Except for the commas! >> >> I looked up comma operator but am still confused. >> >> Wouldn't this be OK (better?) >> >> var el = (typeof obj == 'string') ? document.getElementById(obj) : obj; >> w = el.offsetWidth ; >> h = el.offsetHeight; >> ... >> > > No, because the ";" marks the end of the variable declaration list. In > the above code, you are indeed creating an implied global variable > called h, No, it creates, if it succeeds (and does not throw an exception, as observed in some instances with MSHTML before, and required in ECMAScript Ed. 5 strict mode), a property with that name of the ECMAScript Global object or overwrites a property with that name of an object in the scope chain. > instead of creating a private variable in the function scope. The proper terminology here is "_local_ variable", not what you wrote. Visibility modifiers do not exist in these implementations; privacy can only be achieved implicitly, through closures. So far there is no closure in that code regarding those variables. > it is one of the JavaScript best practices to declare all of the > variables used in a function at the top of the function body. You may > have many variables separated by commas, e.g > > var el = ..., > h = ..., > w = ..., > i, j, len, ..., z; > > You must not use multiple var statements such as: > var el; > var h = ...; > var z; Wrong. In fact, it turns out that syntactically *correct*, adjacent `var' statements work better with editors capable of refactoring, such as Eclipse JSDT. And they help to avoid the problem that you encountered, because it would likely be a syntax error if you mistyped the semicolon, and automatic semicolon insertion would take place if you forgot to type the semicolon at all. PointedEars -- Anyone who slaps a 'this page is best viewed with Browser X' label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network. -- Tim Berners-Lee
[toc] | [prev] | [next] | [standalone]
| From | "J.R." <groups_jr-1@yahoo.com.br> |
|---|---|
| Date | 2011-11-14 13:03 -0200 |
| Message-ID | <j9raj8$ft3$1@speranza.aioe.org> |
| In reply to | #8310 |
On 14/11/2011 10:15, Thomas 'PointedEars' Lahn wrote: >>> var el = (typeof obj == 'string') ? document.getElementById(obj) : obj; >>> w = el.offsetWidth ; >>> h = el.offsetHeight; >>> ... >>> >> >> No, because the ";" marks the end of the variable declaration list. In >> the above code, you are indeed creating an implied global variable >> called h, > > No, it creates, if it succeeds (and does not throw an exception, as observed > in some instances with MSHTML before, and required in ECMAScript Ed. 5 > strict mode), a property with that name of the ECMAScript Global object or > overwrites a property with that name of an object in the scope chain. Considering only the given code by Cal, it creates two implied global variables (w and h), according to ECMA-262 3rd, section 12.2: "If the variable statement occurs inside a FunctionDeclaration, the variables are defined with function-local scope in that function, as described in s10.1.3. Otherwise, they are defined with *global scope* (that is, they are created as members of the global object, as described in 10.1.3) [...]" > >> instead of creating a private variable in the function scope. > > The proper terminology here is "_local_ variable", not what you wrote. As written above, the correct terminology is indeed "variable defined in the function-local scope". > Visibility modifiers do not exist in these implementations; privacy can > only be achieved implicitly, through closures. So far there is no closure > in that code regarding those variables. ACK, except for the *only*. >> it is one of the JavaScript best practices to declare all of the >> variables used in a function at the top of the function body. You may >> have many variables separated by commas, e.g >> >> var el = ..., >> h = ..., >> w = ..., >> i, j, len, ..., z; >> >> You must not use multiple var statements such as: >> var el; >> var h = ...; >> var z; > > Wrong. In fact, it turns out that syntactically *correct*, adjacent `var' > statements work better with editors capable of refactoring, such as Eclipse > JSDT. It's not wrong, it's a different approach instead. ECMAScript permits using either a single var or many var statements as one wishes. I prefer the single var pattern. And I don't care about Eclipse - I'm talking about JavaScript not JAVA. Personally, I prefer Python / Django but it doesn't matter to this discussion anyway. > And they help to avoid the problem that you encountered, because it > would likely be a syntax error if you mistyped the semicolon, and automatic > semicolon insertion would take place if you forgot to type the semicolon at > all. ACK. -- Joao Rodrigues (J.R.)
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2011-11-14 17:24 +0100 |
| Message-ID | <1634456.94akUBOfGJ@PointedEars.de> |
| In reply to | #8318 |
J.R. wrote: > On 14/11/2011 10:15, Thomas 'PointedEars' Lahn wrote: >>>> var el = (typeof obj == 'string') ? document.getElementById(obj) : obj; >>>> w = el.offsetWidth ; >>>> h = el.offsetHeight; >>>> ... >>>> >>> >>> No, because the ";" marks the end of the variable declaration list. In >>> the above code, you are indeed creating an implied global variable >>> called h, >> >> No, it creates, if it succeeds (and does not throw an exception, as >> observed in some instances with MSHTML before, and required in ECMAScript >> Ed. 5 strict mode), a property with that name of the ECMAScript Global >> object or overwrites a property with that name of an object in the scope >> chain. > > Considering only the given code by Cal, it creates two implied global > variables (w and h), No. What happens is what I described, which is compliant with ECMAScript Edition 3 Final, sections 11.13.1 and 8.6.2, and Editions 5 and 5.1, sections 11.13.1 and 8.7.2, respectively. > according to ECMA-262 3rd, section 12.2: The current edition of ECMAScript is 5.1, June 2011 CE; not Edition 3 (Final), December 1999/March 2000 CE. > "If the variable statement occurs inside a FunctionDeclaration, the > variables are defined with function-local scope in that function, as > described in s10.1.3. Otherwise, they are defined with *global scope* > (that is, they are created as members of the global object, as described > in 10.1.3) [...]" That section's second sentence refers to *variable statements* outside of a FunctionDeclaration, as made obvious by its first sentence. >>> instead of creating a private variable in the function scope. >> The proper terminology here is "_local_ variable", not what you wrote. > > As written above, the correct terminology is indeed "variable defined in > the function-local scope". No, a "variable defined *with* function-local scope" is something else than "a variable defined *in* the function-local scope" (which you also did not say before). The proper term for such a variable is _local_ variable, _not_ a "private" variable (whereas you said the latter before). >> Visibility modifiers do not exist in these implementations; privacy can >> only be achieved implicitly, through closures. So far there is no >> closure in that code regarding those variables. > > ACK, except for the *only*. Please name a counter-example using ECMAScript-conforming code where a `private'-like property visibility is achieved explicitly. >>> it is one of the JavaScript best practices to declare all of the >>> variables used in a function at the top of the function body. You may >>> have many variables separated by commas, e.g >>> >>> var el = ..., >>> h = ..., >>> w = ..., >>> i, j, len, ..., z; >>> >>> You must not use multiple var statements such as: >>> var el; >>> var h = ...; >>> var z; >> >> Wrong. In fact, it turns out that syntactically *correct*, adjacent >> `var' statements work better with editors capable of refactoring, such as >> Eclipse JSDT. > > It's not wrong, it's a different approach instead. No, it is wrong to say "must not use". "Must not" in English means "is not allowed to". It is certainly allowed to use that syntactical construct, as it constitutes nothing more than consecutive statements. > ECMAScript permits using either a single var or many var statements as one > wishes. That is not what you said before. > I prefer the single var pattern. That is also not what you said before. > And I don't care about Eclipse - I'm talking about JavaScript not JAVA. Will you please at least *try* get yourself educated before you post? Eclipse JSDT is the Eclipse _JavaScript_ Development Tools plugin. > Personally, I prefer Python / Django but it doesn't matter to this > discussion anyway. Yes, it matters how a commonly used JavaScript IDE can deal with either of those syntactical constructs. PointedEars -- Danny Goodman's books are out of date and teach practices that are positively harmful for cross-browser scripting. -- Richard Cornford, cljs, <cife6q$253$1$8300dec7@news.demon.co.uk> (2004)
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2011-11-14 13:00 +0100 |
| Message-ID | <1543400.qVoOGUtdWV@PointedEars.de> |
| In reply to | #8292 |
Cal Who wrote: > > >> But I will still ignore you if you (continue to) post with an invalid >> From/Reply-To header field value. Usenet can only work if communication >> works both ways. > > I have no idea what it is about. I use IE Express You mean _Outlook_ Express, as it says in the `X-Newsreader' header field of your postings [1]. > and reply with "Reply Group" > Do I have something set up wrong? > ' Yes. One cannot send e-mail to your sender (`From') "address" (which therefore isn't one). This violates NetNews/Internet standards and disregards Netiquette (network etiquette). (And a comparably minor thing: There is a leading space in your "name", which should be your real name.) F'up2 poster (i. e., please reply by e-mail *only*; check headers before you send, as your outdated program has a bug there – by default it sends to the newsgroup, too [2]. TIA.) PointedEars ___________ [1] <http://email.about.com/od/outlookexpresssourceview/qt/Display_all_Header_Lines_Windows_Live_Mail_Outlook_Express.htm> [2] <http://insideoe.com/>
[toc] | [prev] | [next] | [standalone]
| From | John G Harris <john@nospam.demon.co.uk> |
|---|---|
| Date | 2011-11-14 15:05 +0000 |
| Message-ID | <YFJhShBe4SwOFwhm@J.A830F0FF37FB96852AD08924D9443D28E23ED5CD> |
| In reply to | #8289 |
On Sun, 13 Nov 2011 at 20:26:47, in comp.lang.javascript, Thomas
'PointedEars' Lahn wrote:
<snip>
>But I will still ignore you if you (continue to) post with an invalid
>From/Reply-To header field value. Usenet can only work if communication
^^^^^^
>works both ways.
<snip>
What have e-mail addresses got to do with Usenet communication ?
John
--
John Harris
[toc] | [prev] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | comp.lang.javascript
csiph-web