On Mar 10, 2011, at 9:55 AM, John Hawkinson wrote:

> but why bother to initialize foo to null? The truthiness of null and
> and undefined is the same...

True, it's not necessary in this case.

> > My point previously was that regardless of warnings or not, if a
> > small tweak in my code will eliminate the warning, I err on the side
> > of just making the cosmetic change, even if I know the warning
>
> Looks like you didn't finish that sentence...

I err on the side of just making the cosmetic change, even if I know the warning
is not really going to affect the code.

> I do have to say, it makes me sad that the in the name of avoiding standalone
> expressions, we have to add an extra level of braces that make the code
> harder to read.

Anonymous functions are generally hard to read, esp. when on the same line. I
use http://prettydiff.com if presented with something which is hard to read.
It's another awesome tool to make code more readable.

foo && foo.m()

is a nice construct, but the assumption is that jslint is trying to avoid the
issue where you want to assign something, but forgot to. So,

var x = foo && foo.m();

validates, but

foo && foo.m()

doesn't. It could be an error if you actually did want to use the expression
result, which && returns.

And:

if (foo) {
	 foo.m();
}

returns nothing, which is what is wanted in this case.

As for harder to read, we're really nitting picks at this point.

Cheers,

-Kent.
--
Kent Davidson
Market Ruler, LLC
Marketing Power Tools
http://marketruler.com/?_cr=efoot
+1 866-622-8636 x88



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

In response to the last question,

**********
--- In jslint_com@yahoogroups.com, John Hawkinson <jhawk@...> wrote:
> Actually, you proposed:
>
>   var foo = null;
>   foo = bar(function() { if (foo) { foo.m(); } }); // Case 5
>
> but why bother to initialize foo to null? The truthiness of null and
> and undefined is the same...
**********

The Truthiness of null and undefined are not the same.
while null == undefined is true, null === undefined is false; if the Truthiness
was the same then null ===  undefined would be true.
Also the intent of null and undefined are different in nature. When a variable
is declared it is by definition is undefined. Which is to say it is not empty,
but rather that it has yet to be defined. Null is a empty state, think of Null
in terms of math with help with this concept as null is also known as the empty
set. Undefined in math terms and null (empty) in math terms are not equivalent
(undefined !== null) but they are similar (undefined == null).


Declare but leave uninitialized

var someVariable1; // assignment to undefined is understood
var someVariable2 = undefined; // does the same as example 1 but will throw lint
warning, use example 1

someVariable1 = 123; // assign value to variable
someVariable1 = undefined; // destruct variable but leave declared

Declare and initialize to empty
var someVariable3 = null;
someVariable1 = 123; // assign value to variable
someVariable1 = null; // empty variable


Hope this short post clears up confusion between undefined and null.

I would like to add that while undefined means "I don't have a clue what
the value might be", null means "I know it has no value" (a known
unknown :-P ).   Beyond a certain point in the application, undefined
might mean there is an error, null means I know it has no value.

If more languages had null and undefined we wouldn't have silly
conventions like indexOf returning -1 when an item was not found. In
JavaScript it is an unfortunate legacy of other languages. Ideally, you
could have:

var position = 'abc'.indexOf('a') sets position to 0
var position = 'abc'.indexOf('x') should set position to null, not -1
var position = null.indexOf('a') should leave position undefined
(assuming the error was not caught)

All those (0, null and undefined) are falsy but they are far from
meaning the same. The last one shows why I said that a variable set to
undefined might signal an error when found beyond a certain point.

In the second case, returning false would also be an arbitrary
convention, just as -1 is.  It might be agreed that false means 'it is
not there' but indexOf asks for the position of the item sought, not if
it is there (where false would be a logical reply)  and if it is not
there, it has no position, no such thing, thus null, not false.  Anyway,
this is beyond the point.

Satyam


El 10/03/2011 17:53, abyssoft@... escribió:
>
> In response to the last question,
>
> **********
> --- In jslint_com@yahoogroups.com
> <mailto:jslint_com%40yahoogroups.com>, John Hawkinson <jhawk@...> wrote:
> > Actually, you proposed:
> >
> > var foo = null;
> > foo = bar(function() { if (foo) { foo.m(); } }); // Case 5
> >
> > but why bother to initialize foo to null? The truthiness of null and
> > and undefined is the same...
> **********
>
> The Truthiness of null and undefined are not the same.
> while null == undefined is true, null === undefined is false; if the
> Truthiness was the same then null === undefined would be true.
> Also the intent of null and undefined are different in nature. When a
> variable is declared it is by definition is undefined. Which is to say
> it is not empty, but rather that it has yet to be defined. Null is a
> empty state, think of Null in terms of math with help with this
> concept as null is also known as the empty set. Undefined in math
> terms and null (empty) in math terms are not equivalent (undefined !==
> null) but they are similar (undefined == null).
>
> Declare but leave uninitialized
>
> var someVariable1; // assignment to undefined is understood
> var someVariable2 = undefined; // does the same as example 1 but will
> throw lint warning, use example 1
>
> someVariable1 = 123; // assign value to variable
> someVariable1 = undefined; // destruct variable but leave declared
>
> Declare and initialize to empty
> var someVariable3 = null;
> someVariable1 = 123; // assign value to variable
> someVariable1 = null; // empty variable
>
> Hope this short post clears up confusion between undefined and null.
>
>
> ------------------------------------------------------------------------
>
> No virus found in this message.
> Checked by AVG - www.avg.com <http://www.avg.com>
> Version: 10.0.1204 / Virus Database: 1497/3495 - Release Date: 03/09/11
>


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

Hello,

      Problem at line 9 character 7: Unexpected 'continue'.


I now get an error like the above with loops that have a 'continue' of the form
shown in the sample code below.

Is this a bug in jslint or is it now enforcing some form I am not aware of?

// --- start sample code ---
var nop = function () {
  return;
};

var test = function () {
  var i;
  for (i=0; i<10; i+=1) {
    if (i<5) {
      continue;
    }
    nop();
  }
};
// --- end sample code ---

Thanks in advancet,

Lindsay





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

It's not a bug, JSLint has a new(ish) "Tolerate continue" option. You can check
that box in options, or add /*jslint continue:true*/ to your code.

Or you could refactor your code to avoid the use of continue. In your example,
you could just set i = 5 in the loop and drop the if check, or check if i > 5
then run nop().

-Randall

--- In jslint_com@yahoogroups.com, Lindsay John Lawrence <thinknlive@...> wrote:
>
> Hello,
>
>       Problem at line 9 character 7: Unexpected 'continue'.
>
>
> I now get an error like the above with loops that have a 'continue' of the
form shown in the sample code below.
>
> Is this a bug in jslint or is it now enforcing some form I am not aware of?
>
> // --- start sample code ---
> var nop = function () {
>   return;
> };
>
> var test = function () {
>   var i;
>   for (i=0; i<10; i+=1) {
>     if (i<5) {
>       continue;
>     }
>     nop();
>   }
> };
> // --- end sample code ---
>
> Thanks in advancet,
>
> Lindsay
>
>
>
>
>
> [Non-text portions of this message have been removed]
>

Thanks! Why the change though? Is 'continue' being deprecated in the language?

--Lindsay


--- On Thu, 3/10/11, spence.randall@... <randall@...> wrote:

From: spence.randall@... <randall@...>
Subject: [jslint] Re: JSLint Bug?
To: jslint_com@yahoogroups.com
Date: Thursday, March 10, 2011, 11:00 AM







 













It's not a bug, JSLint has a new(ish) "Tolerate continue" option. You can check
that box in options, or add /*jslint continue:true*/ to your code.



Or you could refactor your code to avoid the use of continue. In your example,
you could just set i = 5 in the loop and drop the if check, or check if i > 5
then run nop().



-Randall



--- In jslint_com@yahoogroups.com, Lindsay John Lawrence <thinknlive@...> wrote:

>

> Hello,

>

>       Problem at line 9 character 7: Unexpected 'continue'.

>

>

> I now get an error like the above with loops that have a 'continue' of the
form shown in the sample code below.

>

> Is this a bug in jslint or is it now enforcing some form I am not aware of?

>

> // --- start sample code ---

> var nop = function () {

>   return;

> };

>

> var test = function () {

>   var i;

>   for (i=0; i<10; i+=1) {

>     if (i<5) {

>       continue;

>     }

>     nop();

>   }

> };

> // --- end sample code ---

>

> Thanks in advancet,

>

> Lindsay

>

>

>

>

>

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

>

























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

Deprecated? No, I don't think so. There are almost always better ways of writing
statements that more explicitly define what you are attempting to do without
resorting to continue. JSLint is all about the good parts, and not about the
parts that are acceptable. It forces you to use a higher standard than the one
defined.

Douglas says it best in his book:

"The continue statement jumps to the top of the loop. I have never seen a piece
of code that was not improved by refactoring it to remove the continue
statement."

-Randall

--- In jslint_com@yahoogroups.com, Lindsay John Lawrence <thinknlive@...> wrote:
>
> Thanks! Why the change though? Is 'continue' being deprecated in the language?
>
> --Lindsay
>
>
> --- On Thu, 3/10/11, spence.randall@... <randall@...> wrote:
>
> From: spence.randall@... <randall@...>
> Subject: [jslint] Re: JSLint Bug?
> To: jslint_com@yahoogroups.com
> Date: Thursday, March 10, 2011, 11:00 AM
>
>
>
>
>
>
>
>  
>
>
>
>
>
>
>
>
>
>
>
>
>
> It's not a bug, JSLint has a new(ish) "Tolerate continue" option. You can
check that box in options, or add /*jslint continue:true*/ to your code.
>
>
>
> Or you could refactor your code to avoid the use of continue. In your example,
you could just set i = 5 in the loop and drop the if check, or check if i > 5
then run nop().
>
>
>
> -Randall
>
>
>
> --- In jslint_com@yahoogroups.com, Lindsay John Lawrence <thinknlive@> wrote:
>
> >
>
> > Hello,
>
> >
>
> >       Problem at line 9 character 7: Unexpected 'continue'.
>
> >
>
> >
>
> > I now get an error like the above with loops that have a 'continue' of the
form shown in the sample code below.
>
> >
>
> > Is this a bug in jslint or is it now enforcing some form I am not aware of?
>
> >
>
> > // --- start sample code ---
>
> > var nop = function () {
>
> >   return;
>
> > };
>
> >
>
> > var test = function () {
>
> >   var i;
>
> >   for (i=0; i<10; i+=1) {
>
> >     if (i<5) {
>
> >       continue;
>
> >     }
>
> >     nop();
>
> >   }
>
> > };
>
> > // --- end sample code ---
>
> >
>
> > Thanks in advancet,
>
> >
>
> > Lindsay
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > [Non-text portions of this message have been removed]
>
> >
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>

Thanks! I have read that book cover to cover several times and it continues to
be an excellent reference... somehow I missed that statement of his though.

--- On Thu, 3/10/11, spence.randall@... <randall@...> wrote:

From: spence.randall@... <randall@...>
Subject: [jslint] Re: JSLint Bug?
To: jslint_com@yahoogroups.com
Date: Thursday, March 10, 2011, 11:47 AM







 













Deprecated? No, I don't think so. There are almost always better ways of writing
statements that more explicitly define what you are attempting to do without
resorting to continue. JSLint is all about the good parts, and not about the
parts that are acceptable. It forces you to use a higher standard than the one
defined.



Douglas says it best in his book:



"The continue statement jumps to the top of the loop. I have never seen a piece
of code that was not improved by refactoring it to remove the continue
statement."



-Randall



--- In jslint_com@yahoogroups.com, Lindsay John Lawrence <thinknlive@...> wrote:

>

> Thanks! Why the change though? Is 'continue' being deprecated in the language?

>

> --Lindsay

>

>

> --- On Thu, 3/10/11, spence.randall@... <randall@...> wrote:

>

> From: spence.randall@... <randall@...>

> Subject: [jslint] Re: JSLint Bug?

> To: jslint_com@yahoogroups.com

> Date: Thursday, March 10, 2011, 11:00 AM

>

>

>

>

>

>

>

>  

>

>

>

>

>

>

>

>

>

>

>

>

>

> It's not a bug, JSLint has a new(ish) "Tolerate continue" option. You can
check that box in options, or add /*jslint continue:true*/ to your code.

>

>

>

> Or you could refactor your code to avoid the use of continue. In your example,
you could just set i = 5 in the loop and drop the if check, or check if i > 5
then run nop().

>

>

>

> -Randall

>

>

>

> --- In jslint_com@yahoogroups.com, Lindsay John Lawrence <thinknlive@> wrote:

>

> >

>

> > Hello,

>

> >

>

> >       Problem at line 9 character 7: Unexpected 'continue'.

>

> >

>

> >

>

> > I now get an error like the above with loops that have a 'continue' of the
form shown in the sample code below.

>

> >

>

> > Is this a bug in jslint or is it now enforcing some form I am not aware of?

>

> >

>

> > // --- start sample code ---

>

> > var nop = function () {

>

> >   return;

>

> > };

>

> >

>

> > var test = function () {

>

> >   var i;

>

> >   for (i=0; i<10; i+=1) {

>

> >     if (i<5) {

>

> >       continue;

>

> >     }

>

> >     nop();

>

> >   }

>

> > };

>

> > // --- end sample code ---

>

> >

>

> > Thanks in advancet,

>

> >

>

> > Lindsay

>

> >

>

> >

>

> >

>

> >

>

> >

>

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

>

> >

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

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

>

























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

I don't want to tolerate unfiltered forins, though.

--- In jslint_com@yahoogroups.com, "spence.randall@..." <randall@...> wrote:
>
>
>
>
>
>
> The "Tolerate unfiltered forin" is off by default, so you would want to check
the appropriate box in Options or add /*jslint forin: true */, then you will no
longer receive the warning.
>
> - Randall
>
> --- In jslint_com@yahoogroups.com, "Ezequiel" <thehungerforce@> wrote:
> >
> >
> > --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@> wrote:
> > >
> > > --- In jslint_com@yahoogroups.com, "Ezequiel" <thehungerforce@> wrote:
> > > >
> > > > Because I'm using my own function for the if statement, this doesn't
work:
> > > >
> > > > example:
> > > >
> > > >  var isOwnProperty, object, i;
> > > >
> > > > isOwnProperty = function(object, key) {....};
> > > >
> > > > object = {zero: 0};
> > > >
> > > > for (i in object) {
> > > >     if (isOwnProperty(object, i)) {
> > > >         ...
> > > >     }
> > > > }
> > > >
> > > > However, it works if my if statement was something like...
object.hasOwnProperty(i);
> > >
> > >
> > > You turned on the forin option. You can not do that.
> > >
> >
> > No, I did not have any options turned on when I ran that snippet.
> >
>

I remember reading JSLint's source and seeing a is_own function to filter
forins.

Apparently, it seems Crockford has switched to actually writing
Object.hasOwnProperty.call out every single time and jslint followed
accordingly. Okay.


--- In jslint_com@yahoogroups.com, "Ezequiel" <thehungerforce@...> wrote:
>
> Because I'm using my own function for the if statement, this doesn't work:
>
> example:
>
>  var isOwnProperty, object, i;
>
> isOwnProperty = function(object, key) {....};
>
> object = {zero: 0};
>
> for (i in object) {
>     if (isOwnProperty(object, i)) {
>         ...
>     }
> }
>
> However, it works if my if statement was something like...
object.hasOwnProperty(i);
>

JSLint now has an Assume Node.js option that predefines global variables for
Node.js. http://nodejs.org/

Hello.

I started using express, a framework for node.js.

The following line

app.use(express.static(__dirname + '/live'));

gets

Expected an identifier and instead saw 'static' (a reserved word)

Is it a correct warning or the reserved words are fine when used as properties
[1]?

Thanks in advance,
Alberto

[1] https://github.com/visionmedia/express/issues/589

--- In jslint_com@yahoogroups.com, "IceBox" <albertosantini@...> wrote:
>
> Is it a correct warning or the reserved words are fine when used as properties
[1]?
>

I read the following topic:
http://tech.groups.yahoo.com/group/jslint_com/message/543

It seems JSLint is right. :)

Regards,
Alberto

Many node scripts begin with

#!/usr/bin/env node

Will you please ignore "#!whatever" if it is the first line?

AJ ONeal


On Tue, Mar 22, 2011 at 2:46 PM, douglascrockford <douglas@...>wrote:

>
>
> JSLint now has an Assume Node.js option that predefines global variables
> for Node.js. http://nodejs.org/
>


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

The Assume a browser option now includes 'window. Most uses of window are in
support of bad practices, but some uses of it are now required by ES5/strict.
For example,

     addEventListener(...);

will probably fail in strict mode, while

     window.addEventLister(...);

will probably succeed because strict mode no longer binds this to the global
object in function form invocations.

Is there some place an interested person could read about the good vs. bad
uses of `window`?

On Tue, Mar 29, 2011 at 8:13 AM, Douglas Crockford <douglas@...>wrote:

>
>
> The Assume a browser option now includes 'window. Most uses of window are
> in support of bad practices, but some uses of it are now required by
> ES5/strict. For example,
>
> addEventListener(...);
>
> will probably fail in strict mode, while
>
> window.addEventLister(...);
>
> will probably succeed because strict mode no longer binds this to the
> global object in function form invocations.
>
>
>


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

--- In jslint_com@yahoogroups.com, Erik Eckhardt <erik@...> wrote:

> Is there some place an interested person could read about the good vs. bad
> uses of `window`?

The principle misuse is to access global variables. Global variables should be
avoided.

Doug,

I saw that someone tried to push a commit with the CommonJS export and it
was rejected.

However, since your JSLINT file can't be exported as a module there are at
least 6 different node-xyz-jslint projects on github with over 24 forks.
Can we discuss a simple change that would make your jslint a module and
hence lead to less fragmentation in the community?

Here's a decent, valid JavaScript solution that makes no crazy assumptions:

var global = global || (function () { return this; }());
(function () {
    "use strict";

    //
    // your current code as is
    //

    if (global.window) {
        global.window.JSLINT = JSLINT;
    }
    if (global.module) {
        global.module.exports = JSLINT;
    }
}());

Do you have a better suggestion?

What would be acceptable to you?

AJ ONeal


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

And it would also be nice to have

    - a simple example jslint commandline utility for Node.JS
    - other examples for other interpreters
    - some example javascript files showing a suggested use for JSLINT and
    it's options


Example of an Example:

/*global global:false */
var MYMODULE;
(function () {
   "use strict";
   /*jslint bitwise: true*/

   function floor(num) {
     /*jslint bitwise: false*/
    return num >> 0;
   }

   MYMODULE = stringToZero
   if (global.module) {
     global.module = MYMODULE;
   }
}());

AJ ONeal

On Tue, Mar 29, 2011 at 2:41 PM, AJ ONeal <coolaj86@...> wrote:

> Doug,
>
> I saw that someone tried to push a commit with the CommonJS export and it
> was rejected.
>
> However, since your JSLINT file can't be exported as a module there are at
> least 6 different node-xyz-jslint projects on github with over 24 forks.
> Can we discuss a simple change that would make your jslint a module and
> hence lead to less fragmentation in the community?
>
> Here's a decent, valid JavaScript solution that makes no crazy assumptions:
>
> var global = global || (function () { return this; }());
> (function () {
>    "use strict";
>
>    //
>    // your current code as is
>    //
>
>    if (global.window) {
>        global.window.JSLINT = JSLINT;
>    }
>    if (global.module) {
>        global.module.exports = JSLINT;
>    }
> }());
>
> Do you have a better suggestion?
>
> What would be acceptable to you?
>
> AJ ONeal
>


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

Could this only be enabled if one opts into "use strict"?

Rob


-----Original Message-----
From: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] On
Behalf Of Douglas Crockford
Sent: Tuesday, March 29, 2011 8:14 AM
To: jslint_com@yahoogroups.com
Subject: [jslint] window

The Assume a browser option now includes 'window. Most uses of window are in
support of bad practices, but some uses of it are now required by
ES5/strict. For example,

     addEventListener(...);

will probably fail in strict mode, while

     window.addEventLister(...);

will probably succeed because strict mode no longer binds this to the global
object in function form invocations.

If you were creating a specialized code library, what method would you use
to "namespace" all the functions in use by that library? Since functions are
themselves globals, would you just create a single "master" object, itself
global, with all other variables inside of it? Then, in commons use, either
use this.fn() or libraryname.fn() all over the place instead of just fn()
when you want to use a function? And something similar for any variables
that are needed to control the operation of the code library (say it's a
popup widget that needs to keep track of all the open popups and whether a
particular popup template has been loaded via ajax or not)?

On Tue, Mar 29, 2011 at 8:57 AM, Douglas Crockford <douglas@...>wrote:

>
>
> --- In jslint_com@yahoogroups.com, Erik Eckhardt <erik@...> wrote:
>
> > Is there some place an interested person could read about the good vs.
> bad
> > uses of `window`?
>
> The principle misuse is to access global variables. Global variables should
> be avoided.
>
>
>


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

Classification: UNCLASSIFIED


On 03/29/11, Erik Eckhardt  <erik@...> wrote:

> If you were creating a specialized code library, what method would you use
> to "namespace" all the functions in use by that library? Since functions are
> themselves globals, would you just create a single "master" object, itself
> global, with all other variables inside of it? Then, in commons use, either
> use this.fn() or libraryname.fn() all over the place instead of just fn()
> when you want to use a function? And something similar for any variables
> that are needed to control the operation of the code library (say it's a
> popup widget that needs to keep track of all the open popups and whether a
> particular popup template has been loaded via ajax or not)?
>

var o = { // global object
     first: function (xyz) {
         return xyz;
     },
     second: function (abc) {
         return abc;
     }
};

o.first(); // this executes the first function from above
o.second(); // this executes the second function from above

This works because the functions are members of a named object, therefore
the functions are references as object properties bound to the named object.

My suggestion is to never use this:
function nameof () {}

Instead always use either the form in the example or this form:
var asdf = function () {};

If this fails to answer your question please let me know.

Austin Cheney, CISSP
http://prettydiff.com/

Classification: UNCLASSIFIED

The `node` option should also include `setInterval` and `setTimeout`, as
they are built-in in node.

AJ ONeal

On Mon, Mar 28, 2011 at 5:32 PM, Douglas Crockford <douglas@...>wrote:

>
>
> --- In jslint_com@yahoogroups.com, AJ ONeal <coolaj86@...> wrote:
> >
> > Many node scripts begin with
> >
> > #!/usr/bin/env node
> >
> > Will you please ignore "#!whatever" if it is the first line?
>
> No, because that is a violation of the standard. I recommend instead that
> you peel off the first line before submitting it to JSLint.
>
>
>


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

What has worked well for me is to create a namespace based on one's domain name,
or a domain name that one owns.

This is discussed in some detail by David Flanagan in his book, JavaScript: The
Definitive Guide (O'Reilly), Paragraph 10.1. See Example 10.1, Creating a
namespace based on a domain name.

In short, assuming domain name, 'mydomain.com', after going through the coding
wickets, you end up with something like this:
// at global scope...
com.mydomain = {};

Then, to add (or "require") a new module 'abc' to your namespace:
if (!com.mydomain.abc) {com.mydomain.abc = (function () {/* lots of code that
returns something */}());}

--- In jslint_com@yahoogroups.com, Erik Eckhardt <erik@...> wrote:
>
> If you were creating a specialized code library, what method would you use
> to "namespace" all the functions in use by that library? Since functions are
> themselves globals, would you just create a single "master" object, itself
> global, with all other variables inside of it? Then, in commons use, either
> use this.fn() or libraryname.fn() all over the place instead of just fn()
> when you want to use a function? And something similar for any variables
> that are needed to control the operation of the code library (say it's a
> popup widget that needs to keep track of all the open popups and whether a
> particular popup template has been loaded via ajax or not)?
>
> On Tue, Mar 29, 2011 at 8:57 AM, Douglas Crockford <douglas@...>wrote:
>
> >
> >
> > --- In jslint_com@yahoogroups.com, Erik Eckhardt <erik@> wrote:
> >
> > > Is there some place an interested person could read about the good vs.
> > bad
> > > uses of `window`?
> >
> > The principle misuse is to access global variables. Global variables should
> > be avoided.
> >
> >
> >
>
>
> [Non-text portions of this message have been removed]
>

Works Correctly
// I'm a Block Comment that has a tab

Has Defect
/*
	 I'm a stream comment  that has a tab
*/

--- In jslint_com@yahoogroups.com, "abyssoft@..." <abyssoft@...> wrote:
>
> Works Correctly
> // I'm a Block Comment that has a tab
>
> Has Defect
> /*
>  I'm a stream comment  that has a tab
> */

JSLint allows tabs. It even allows the mixing of tabs and spaces, which is a bad
practice. Where it draws the line is when it sees a space immediately followed
by a tab.

--- In jslint_com@yahoogroups.com, AJ ONeal <coolaj86@...> wrote:
> The `node` option should also include `setInterval` and `setTimeout`, as
> they are built-in in node.

The node.js documentation is still a bit sketchy, so it is hard to find all of
the globals. Please let me know if you find more.

My biggest nightmare today is that recent browsers like Chrome, IE9, FF4
generate a global variable from the id of each HTMLElement of the document...

It is know possible in these browser to write

domNode = myPanel;

or

domNode = window.myPanel;

instead of

domNode = document.getElementById('myPanel');

or with jQuery:

domNode = $('#myPanel');

Let's imagine the effects of existing HTMLElements with id like "location",
"document", "event", "toolbar", or even "window"...

What should be the list of reserved keywords for valid id value ?
All the BOM API ?
+ APIs like Web Storages, Web Sockets... ?
+ Global namespaces of common Ajax frameworks ?

And what about future HTML5/W3C APIs ?
And what about future or private frameworks ???

So ... "window.myPanel"
-> Bad practice isn't it ?

That is a nightmare!

I just noticed that a few days ago and it was really upsetting to see even
MORE global leakage... YUCK.

AJ ONeal


On Thu, Mar 31, 2011 at 6:08 AM, Alexandre Morgaut <morgaut@...>wrote:

>
>
> My biggest nightmare today is that recent browsers like Chrome, IE9, FF4
> generate a global variable from the id of each HTMLElement of the
> document...
>
> It is know possible in these browser to write
>
> domNode = myPanel;
>
> or
>
> domNode = window.myPanel;
>
> instead of
>
> domNode = document.getElementById('myPanel');
>
> or with jQuery:
>
> domNode = $('#myPanel');
>
> Let's imagine the effects of existing HTMLElements with id like "location",
> "document", "event", "toolbar", or even "window"...
>
> What should be the list of reserved keywords for valid id value ?
> All the BOM API ?
> + APIs like Web Storages, Web Sockets... ?
> + Global namespaces of common Ajax frameworks ?
>
> And what about future HTML5/W3C APIs ?
> And what about future or private frameworks ???
>
> So ... "window.myPanel"
> -> Bad practice isn't it ?
>
>
>


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

I use this pattern:
https://github.com/coolaj86/require-kiss-js

I'm also going to look into RequireJS in the near future.

AJ ONeal

On Tue, Mar 29, 2011 at 5:17 PM, Erik Eckhardt <erik@...> wrote:

> If you were creating a specialized code library, what method would you use
> to "namespace" all the functions in use by that library? Since functions
> are
> themselves globals, would you just create a single "master" object, itself
> global, with all other variables inside of it? Then, in commons use, either
> use this.fn() or libraryname.fn() all over the place instead of just fn()
> when you want to use a function? And something similar for any variables
> that are needed to control the operation of the code library (say it's a
> popup widget that needs to keep track of all the open popups and whether a
> particular popup template has been loaded via ajax or not)?
>
> On Tue, Mar 29, 2011 at 8:57 AM, Douglas Crockford <douglas@...
> >wrote:
>
> >
> >
> > --- In jslint_com@yahoogroups.com, Erik Eckhardt <erik@...> wrote:
> >
> > > Is there some place an interested person could read about the good vs.
> > bad
> > > uses of `window`?
> >
> > The principle misuse is to access global variables. Global variables
> should
> > be avoided.
> >
> >
> >
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>


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