On Sun, May 31, 2009 at 7:32 PM, Douglas Crockford <douglas@...>wrote:

>> ... it is best to explicitly use var to declare all global variables ...



Can you please explain why in more detail?  Could not declaring the same

variable more than once could also lead to confusion?  I think when most

people see the var statement they assume it's the primary declaration of

that variable.



Thanks





[Non-text portions of this message have been removed]

As with the others that have commented.

I was very excited when this feature was introduced, and find it very useful.



I often have multiple js files that are compiled into one file during my build

process.

The /*global */ feature allows me to use jslint without the headache of writing

dummy declarations in each file.



I would hate to see this disappear.





--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:

>

> I will be removing the /*global */ declarative comment. I am persuaded that it

is best to explicitly use var to declare all global variables, even when

accessing variables created by other compilation units.

>

> /*global */ will just be a comment.

>

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:

>

> I will be removing the /*global */ declarative comment. I am persuaded that it

is best to explicitly use var to declare all global variables, even when

accessing variables created by other compilation units.

>

> /*global */ will just be a comment.

>



In answer to people's concerns: I believe the primary reason for this change is

that "use strict" mode does not allow implied globals:

http://tech.groups.yahoo.com/group/jslint_com/message/540



Now, rather than writing:

/*global varName */



You simply write:

var varName;



Disclaimer: I am not Douglas Crockford, so this is merely my own personal

speculation on the subject.

I also find removing the support for /*global */ to be a major setback.



Combining several JavaScript files into one for deployment is somewhat a must.

In most of the applications I work on such a file would include possibly several

hundred "var $;" statements. That's obviously unacceptable, so we would

effectively have to stop using JSLint if this was enforced. If it was an option

we would always turn it off, regardless of the reasoning behind it.



Please keep support for /*global */.



Just my two cents.



/Jakob









From: pauanyu [mailto:pcxunlimited@...]

To: jslint_com@yahoogroups.com

Sent: Mon, 01 Jun 2009 18:39:57 +0200

Subject: [jslint] Re: /*global */



--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:

>

> I will be removing the /*global */ declarative comment. I am persuaded that it

is best to explicitly use var to declare all global variables, even when

accessing variables created by other compilation units.

>

> /*global */ will just be a comment.

>



In answer to people's concerns: I believe the primary reason for this change is

that "use strict" mode does not allow implied globals:

http://tech.groups.yahoo.com/group/jslint_com/message/540



Now, rather than writing:

/*global varName */



You simply write:

var varName;



Disclaimer: I am not Douglas Crockford, so this is merely my own personal

speculation on the subject.

--- In jslint_com@yahoogroups.com, "Jakob Kruse" <kruse@...> wrote:

>

> I also find removing the support for /*global */ to be a major setback.

>

> Combining several JavaScript files into one for deployment is somewhat a must.

In most of the applications I work on such a file would include possibly several

hundred "var $;" statements. That's obviously unacceptable, so we would

effectively have to stop using JSLint if this was enforced. If it was an option

we would always turn it off, regardless of the reasoning behind it.

>

> Please keep support for /*global */.

>

> Just my two cents.

>

> /Jakob

>



I seem to be missing something here. Why are people okay with writing:

/*global $ */



But not:

var $;



This is very perplexing to me. Why would you choose a more verbose and

unnecessary syntax that is unsupported by ES5 strict-mode?

On Mon, Jun 1, 2009 at 1:40 PM, pauanyu <pcxunlimited@...> wrote:



>

>

> I seem to be missing something here. Why are people okay with writing:

> /*global $ */

>

> But not:

> var $;

>

> This is very perplexing to me. Why would you choose a more verbose and

> unnecessary syntax that is unsupported by ES5 strict-mode?

> .

>

>

>



It affects compression (albeit only a tiny bit unless you have a lot of

global variables, which you shouldn't anyway...)

And it goes against DRY.

Probably the main reason is just habit... (although that can be changed

obviously.)



I'm not saying I disagree completely, I just want to understand better why

it was done...  Are we really going to see ES5 adopted widely (and

especially cross-browser-wise) any time soon?





[Non-text portions of this message have been removed]

--- In jslint_com@yahoogroups.com, Arthur Blake <arthur.blake@...> wrote:

>

> It affects compression (albeit only a tiny bit unless you have a lot of

> global variables, which you shouldn't anyway...)

> And it goes against DRY.

> Probably the main reason is just habit... (although that can be changed

> obviously.)

>

> I'm not saying I disagree completely, I just want to understand better why

> it was done...  Are we really going to see ES5 adopted widely (and

> especially cross-browser-wise) any time soon?

>



As to your last question: yes.

While in general I approve of being able to turn off warnings, why do you have

"possibly several hundred "var $;" statements"?  You would need at most one per

file and you only have "several" files.



An alternative to turning off the warning would be to mark every such

declaration (e.g. "var $; /* extern */") and then during the minification

process, deleting all those lines.  You'd get the advantage of being warned

about accidental globals without the slow-down in loading.



M.









________________________________

From: Jakob Kruse <kruse@...>

To: jslint_com@yahoogroups.com

Sent: Monday, June 1, 2009 10:23:35 AM

Subject: Re: [jslint] Re: /*global */



I also find removing the support for /*global */ to be a major setback.



Combining several JavaScript files into one for deployment is somewhat a must.

In most of the applications I work on such a file would include possibly several

hundred "var $;" statements. That's obviously unacceptable, so we would

effectively have to stop using JSLint if this was enforced. If it was an option

we would always turn it off, regardless of the reasoning behind it.



Please keep support for /*global */.



Just my two cents.



/Jakob









From: pauanyu [mailto:pcxunlimited@...]

To: jslint_com@yahoogroups.com

Sent: Mon, 01 Jun 2009 18:39:57 +0200

Subject: [jslint] Re: /*global */



--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:

>

> I will be removing the /*global */ declarative comment. I am persuaded that it

is best to explicitly use var to declare all global variables, even when

accessing variables created by other compilation units.

>

> /*global */ will just be a comment.

>



In answer to people's concerns: I believe the primary reason for this change is

that "use strict" mode does not allow implied globals:

http://tech.groups.yahoo.com/group/jslint_com/message/540



Now, rather than writing:

/*global varName */



You simply write:

var varName;



Disclaimer: I am not Douglas Crockford, so this is merely my own personal

speculation on the subject.





------------------------------------



Yahoo! Groups Links







[Non-text portions of this message have been removed]

200-500 javascript files in an application is common where I work. Most of those

files use some JavaScript library, for instance Prototype. All JavaScript

libraries define one or more globals.



Putting a /*global $ */ at the top of every one of those several hundred files

is tedious, but not without informative value (especially if combined with "//

Prototype"), and it is automatically removed when I minify my code for

deployment.



Putting "use strict" and/or var $ at the top of every one of them does

absolutely nothing for me except bloat my application and make it slower. As

such it is unacceptable.



Also, in general there will be somewhat considerable resistance towards moving

to a version of JSLint which will automatically flag every single existing (and

previously valid) JavaScript file as invalid. I think we would rather stay with

an older version for some time and then stop using it altogether.



Also, in response to Douglas' mail offering an explanation (just came in while I

wrote this):



There's a major difference here. I suspect JSLint failed to run because JSLint

itself was declared as "JSLINT = ..." and not "var JSLINT = ...". That would

obviously be a mistake (I did remember seeing a recommendation to skip var for

globals earlier, and I never bought that one either). I find that case

completely different from having to add a "var JSLINT;" to every other

JavaScript file on the planet that uses JSLINT.



Surely JSLint can check that globals are declared/defined using "var my_global =

..." without needing additional "var my_global" statement all over my code?



In general I'm all for JSLint, and I've changed my programming style

considerably to please it (and benefitted from it), but this is not ok.



The var solution even seems to me to offer greater potential of masking errors

than /*global */. If I forget to include the file that actually defines the

global, the /*global */ solution will offer a reasonable error ("my_global is

not defined"). If I var'ed it at the top there will probably be an error, but

not always ("var x;" is identical to "var x = undefined;" so the global will

have a value), and even if there is an error, it will make a lot less sense.



Please reconsider!



/Jakob









From: Michael Lorton [mailto:mlorton@...]

To: jslint_com@yahoogroups.com

Sent: Mon, 01 Jun 2009 19:51:55 +0200

Subject: Re: [jslint] Re: /*global */









While in general I approve of being able to turn off warnings, why do you have

"possibly several hundred "var $;" statements"? You would need at most one per

file and you only have "several" files.



An alternative to turning off the warning would be to mark every such

declaration (e.g. "var $; /* extern */") and then during the minification

process, deleting all those lines. You'd get the advantage of being warned about

accidental globals without the slow-down in loading.



M.



________________________________

From: Jakob Kruse <kruse@...>

To: jslint_com@yahoogroups.com

Sent: Monday, June 1, 2009 10:23:35 AM

Subject: Re: [jslint] Re: /*global */



I also find removing the support for /*global */ to be a major setback.



Combining several JavaScript files into one for deployment is somewhat a must.

In most of the applications I work on such a file would include possibly several

hundred "var $;" statements. That's obviously unacceptable, so we would

effectively have to stop using JSLint if this was enforced. If it was an option

we would always turn it off, regardless of the reasoning behind it.



Please keep support for /*global */.



Just my two cents.



/Jakob



From: pauanyu [mailto:pcxunlimited@...]

To: jslint_com@yahoogroups.com

Sent: Mon, 01 Jun 2009 18:39:57 +0200

Subject: [jslint] Re: /*global */



--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:

>

> I will be removing the /*global */ declarative comment. I am persuaded that it

is best to explicitly use var to declare all global variables, even when

accessing variables created by other compilation units.

>

> /*global */ will just be a comment.

>



In answer to people's concerns: I believe the primary reason for this change is

that "use strict" mode does not allow implied globals:

http://tech.groups.yahoo.com/group/jslint_com/message/540



Now, rather than writing:

/*global varName */



You simply write:

var varName;



Disclaimer: I am not Douglas Crockford, so this is merely my own personal

speculation on the subject.

My first concern with JSLint is correctness. Because I am a deeply flawed human

being, and because JavaScript is a deeply flawed programming language, I depend

on JSLint to provide the necessary discipline to program with confidence.



So when I discover errors in my programs, I think about ways that I can improve

JSLint to avoid similar errors in the future. This sometimes demands that I

change my programming style because my previous style tended to hide defects or

even encourage defects. Evolving my style is sometimes difficult and

occasionally embarrassing, but it is a necessary part of the process of becoming

a better programmer.



I don't like global variables. Global variables contribute to unreliability and

insecurity. JavaScript demands the use of global variables, which is sort of

terrifying. I have spent a lot of time trying to figure out how to mitigate

these globals. I came up with the /*global */ comment because I thought it was

important to indicate when the use of globals was intentional.



But working with ES5/strict, the JSLINT program itself passed JSLint but failed

to run. The failure due to my using a /*global */ comment instead of a var

statement. So now it turns out that /*global */ can mask errors from JSLint.

That forces me to abandon /*global */ and look for a more reliable approach.



That approach is to use top level var statements to declare global variables. It

is the most portable and most reliable approach. It required that I go through

all of my programs and replace



     /*global x, y, z*/



with



     var x, y, z;



It was not a difficult change to make. I tend to use very few global variables,

so there isn't much of an impact. When concatenating multiple script files, that

may result in redundant var statements. That is annoying, but it is not a

hazard, and it is not significant, particularly after gzip.



This language continues to surprise me. I thought I had figured out a good

pattern for handling global variables. It turned out I was wrong. I think this

new pattern is better.

Very well said.  Thanks for explaining that in depth.  I think it makes a

lot of sense now.  Still, it might be nice to have an ES5 strict mode flag

in JSLint that engages the new behavior- but I understand that it's not

JSLint's goal to be all things to everyone (although sometime that's easy to

forget as the tool becomes more and more popular.)   I am assuming that

using the new ES5 strict mode will be recommended as a best practice...





[Non-text portions of this message have been removed]

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:

> But working with ES5/strict, the JSLINT program itself passed

> JSLint but failed to run. The failure due to my using a /*global */

> comment instead of a var statement. So now it turns out that

> /*global */ can mask errors from JSLint. That forces me to abandon

> /*global */ and look for a more reliable approach.



Looking at an older version of jslint.js (2008-11-07), it has the

following lines at the beginning:



| /*global JSLINT*/

|

| // We build the application inside a function so that we produce

| // only a single global variable. The function will be invoked, its

| // return value is the JSLINT application itself.

|

| "use strict";

|

| JSLINT = function () {



The way I understand it, /*global*/ is normally used to disable

warnings about undeclared globals, usually because the programmer

knows that variable is defined elsewhere. I don't know why you used

/*global*/ instead of "var" in this case, but it's not surprising

that JSLint didn't warn you, because you actively told it to suppress

the warning. Looks like it was working as intended.



> This language continues to surprise me. I thought I had figured out

> a good pattern for handling global variables. It turned out I was

> wrong. I think this new pattern is better.



The problem that some of us have with the removal of /*global*/ is

that JSLint now demands declarations that were previously deemed bad

style and actually caused a warning ("... is already defined").

Silencing warnings in a lint checker is a conscious action, and

indicates that the programmer knows something about the program that

the checker can't know (i.e. the existence of other related files).

Randall's point earlier in this thread (implicit predefined globals

like HTMLElement and others) is also very relevant. How can we tell

JSLint to accept these objects now?





   - Conrad

Good.  Perhaps this will inspire people to merge their various JS files into a

single file for output at the CMS layer prior to validation.  That would be the

only way to avoid the resultant undefined errors from code requesting pieces

from other various files.  The only remaining struggle at that point is to

prevent those pesky 'used before it was defined' errors.  I consider such a

completely unintentional efficiency motivator to be extremely beneficial in the

long run.

One thing I can do is to add more Assume options supporting popular Ajax

libraries. If you are responsible for a popular Ajax library with a small,

stable list of predefined globals, then give me the list.

Or, add some extrinsic way of saying, "These are the globals I'm not declaring

but I don't want me to yentz me about."



M.









________________________________

From: Douglas Crockford <douglas@...>

To: jslint_com@yahoogroups.com

Sent: Monday, June 1, 2009 12:22:42 PM

Subject: [jslint] Re: /*global */



One thing I can do is to add more Assume options supporting popular Ajax

libraries. If you are responsible for a popular Ajax library with a small,

stable list of predefined globals, then give me the list.







------------------------------------



Yahoo! Groups Links







[Non-text portions of this message have been removed]

--- In jslint_com@yahoogroups.com, Michael Lorton <mlorton@...> wrote:



> Or, add some extrinsic way of saying, "These are the globals I'm not

> declaring but I don't want me to yentz me about."



Right. You don't throw the baby out with the bathwater, even if the baby is

dead.



So I am keeping /*global */. The variables that it defines will be const. You

can read them and call them,but you can't assign to them. That should prevent

the confusion that caused my problem.

Perfect! :)



/Jakob



----- Original Message -----

From: Douglas Crockford

[mailto:douglas@...]

To: jslint_com@yahoogroups.com

Sent: Mon, 01

Jun 2009 22:10:20 +0200

Subject: [jslint] Re: /*global */





> --- In jslint_com@yahoogroups.com, Michael Lorton <mlorton@...> wrote:

>

> > Or, add some extrinsic way of saying, "These are the globals I'm not

> > declaring but I don't want me to yentz me about."

>

> Right. You don't throw the baby out with the bathwater, even if the baby is

> dead.

>

> So I am keeping /*global */. The variables that it defines will be const.

> You can read them and call them,but you can't assign to them. That should

> prevent the confusion that caused my problem.

>

>

>

On 1 Jun 2009, at 21:10:20, Douglas Crockford wrote:

> So I am keeping /*global */. The variables that it defines will be

> const. You can read them and call them,but you can't assign to them.

> That should prevent the confusion that caused my problem.

>



/*global foo */



foo.opacity = 255;



var f = function () {

	 var foo;

	 foo = 7;

};



Error:

Problem at line 7 character 5: Global violation.

foo = 7;

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:

> So I am keeping /*global */. The variables that it defines will be

> const. You can read them and call them,but you can't assign to them.

> That should prevent the confusion that caused my problem.



Thank you for reconsidering, that's a very elegant solution.





    - Conrad

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:

>

> One thing I can do is to add more Assume options supporting popular Ajax

libraries. If you are responsible for a popular Ajax library with a small,

stable list of predefined globals, then give me the list.

>



For library authors managing separate files and combing at runtime,

what about using the old /*extern */ declaration? That seems

like it would be a reasonable compromise. Just a thought.



- Randall Lee Spence

--- In jslint_com@yahoogroups.com, "Randall Lee Spence" <analogueweb@...> wrote:

>

> --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@> wrote:

> >

> > One thing I can do is to add more Assume options supporting popular Ajax

libraries. If you are responsible for a popular Ajax library with a small,

stable list of predefined globals, then give me the list.

> >

>

> For library authors managing separate files and combing at runtime,

> what about using the old /*extern */ declaration? That seems

> like it would be a reasonable compromise. Just a thought.

>

> - Randall Lee Spence

>



It really make sens to use extern because that exactly what they are.

In my Scripts most of the entries in /*global*/ are not Global variables.

Names in the /*global */ comment may now take a boolean value. true indicates

that the variable is writable. false (the default) indicates that it is const.

This give you greater control in restricting the use of globals.



Note that /*global name: true */ is not quite that same as var name. var name is

required when declaring global variables in strict mode. Use of /*global name:

true */ will suppress that warning.



The assume a browser option is now /*global addEventListener: false, alert:

false, blur: false, clearInterval: false, clearTimeout: false, close: false,

closed: false, confirm: false, console: false, Debug: false, defaultStatus:

false, document: false, event: false, focus: false, frames: false,

getComputedStyle: false, history: false, Image: false, length: false, location:

false, moveBy: false, moveTo: false, name: false, navigator: false, onblur:

true, onerror: true, onfocus: true, onload: true, onresize: true, onunload:

true, open: false, opener: false, opera: false, Option: false, parent: false,

print: false, prompt: false, resizeBy: false, resizeTo: false, screen: false,

scroll: false, scrollBy: false, scrollTo: false, setInterval: false, setTimeout:

false, status: false, top: false, XMLHttpRequest: false */. Notice that the on-

variables are now writable.

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:

>

> Names in the /*global */ comment may now take a boolean value. true indicates

that the variable is writable. false (the default) indicates that it is const.

This give you greater control in restricting the use of globals.

>

> Note that /*global name: true */ is not quite that same as var name. var name

is required when declaring global variables in strict mode. Use of /*global

name: true */ will suppress that warning.

>

> The assume a browser option is now /*global addEventListener: false, alert:

false, blur: false, clearInterval: false, clearTimeout: false, close: false,

closed: false, confirm: false, console: false, Debug: false, defaultStatus:

false, document: false, event: false, focus: false, frames: false,

getComputedStyle: false, history: false, Image: false, length: false, location:

false, moveBy: false, moveTo: false, name: false, navigator: false, onblur:

true, onerror: true, onfocus: true, onload: true, onresize: true, onunload:

true, open: false, opener: false, opera: false, Option: false, parent: false,

print: false, prompt: false, resizeBy: false, resizeTo: false, screen: false,

scroll: false, scrollBy: false, scrollTo: false, setInterval: false, setTimeout:

false, status: false, top: false, XMLHttpRequest: false */. Notice that the on-

variables are now writable.

>



What is the rationale for not allowing overwrites of other global variables,

like alert, prompt, and confirm?

--- In jslint_com@yahoogroups.com, "pauanyu" <pcxunlimited@...> wrote:



> What is the rationale for not allowing overwrites of other global

> variables, like alert, prompt, and confirm?



Why do you want to do that?

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:

>

> --- In jslint_com@yahoogroups.com, "pauanyu" <pcxunlimited@> wrote:

>

> > What is the rationale for not allowing overwrites of other global

> > variables, like alert, prompt, and confirm?

>

> Why do you want to do that?

>



I use a custom alert that is useful for debugging. True, it's a very weak

argument in favor of writable predefined globals, so it isn't really a big deal.

If I absolutely have to have it, I can just use a var.



I'm still curious at the rationale, however. I mean, it's obvious that you

shouldn't try to overwrite things like setTimeout and such, but what about

alert, confirm, prompt, etc.?

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...>

wrote:

>

> --- In jslint_com@yahoogroups.com, "pauanyu" pcxunlimited@ wrote:

>

> > What is the rationale for not allowing overwrites of other global

> > variables, like alert, prompt, and confirm?

>

> Why do you want to do that?

>



Access window.prompt(...) is blocked by the default security settings of

IE7.  Instead of the usual pop-up modal box, the user gets a yellow

security bar from the top of the browser window.  Instead of asking what

you prompted about, the yellow bar prompts the user about whether or not

to allow prompts.  Worse, the call to window.prompt that started the

problem immediately returns [null].



It is possible to restore the original behavior (including pausing

execution until the user provides a value) by using a custom

window.prompt function:



http://chris.photobooks.com/tests/prompt/ie7prompt.html

<http://chris.photobooks.com/tests/prompt/ie7prompt.html>



So, this is why I would want to overwrite prompt.  If I am understanding

this correctly, I can adjust JSLint's behavior to allow this by using

/*global prompt: true */, and that is fine with me.



- Chris







[Non-text portions of this message have been removed]

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:

> The assume a browser option is now /*global [snip] location: false

> [snip] */. Notice that the on- variables are now writable.



"location" should probably also default to true, because assigning a

value to the window.location property is equivalent to assigning to

location.href or calling location.assign().



https://developer.mozilla.org/En/Window.location





   - Conrad

--- In jslint_com@yahoogroups.com, "crlender" <crlender@...> wrote:

> "location" should probably also default to true, because assigning a

> value to the window.location property is equivalent to assigning to

> location.href or calling location.assign().

>

> https://developer.mozilla.org/En/Window.location



Thanks for sharing two superior alternatives.

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:

>

> Names in the /*global */ comment may now take a boolean value. true indicates

that the variable is writable. false (the default) indicates that it is const.

This give you greater control in restricting the use of globals.

>

> Note that /*global name: true */ is not quite that same as var name. var name

is required when declaring global variables in strict mode. Use of /*global

name: true */ will suppress that warning.

>

> The assume a browser option is now /*global addEventListener: false, alert:

false, blur: false, clearInterval: false, clearTimeout: false, close: false,

closed: false, confirm: false, console: false, Debug: false, defaultStatus:

false, document: false, event: false, focus: false, frames: false,

getComputedStyle: false, history: false, Image: false, length: false, location:

false, moveBy: false, moveTo: false, name: false, navigator: false, onblur:

true, onerror: true, onfocus: true, onload: true, onresize: true, onunload:

true, open: false, opener: false, opera: false, Option: false, parent: false,

print: false, prompt: false, resizeBy: false, resizeTo: false, screen: false,

scroll: false, scrollBy: false, scrollTo: false, setInterval: false, setTimeout:

false, status: false, top: false, XMLHttpRequest: false */. Notice that the on-

variables are now writable.

>



"name" needs to be writable. It has no value by default, but you can assign a

string to it, indicating the name of the window/tab.

--- In jslint_com@yahoogroups.com, "pauanyu" <pcxunlimited@...> wrote:

> "name" needs to be writable. It has no value by default,

> but you can assign a string to it, indicating the name of

> the window/tab.



Which do you think is more likely, that a program wants to change the global

name, or that a var name declaration in a function was forgotten? We won't get

an implied global warning, but at least we can get a read only warning. I think

that is the more useful default.