--- In jslint_com@yahoogroups.com, Randy Cox <rcox@...> wrote:
>
> On Tue, Jun 2, 2009 at 4:10 PM, Douglas Crockford <douglas@...> wrote:
> > But then someone showed be a case where new Array(n) is actually useful.
>
> Will you share this useful case, or must it remain a mystery?

Suppose you need to construct a string containing n asterisks.
It seems the fastest way to do that is

     new Array(n + 1).join('*')

First, could JsLint displays the number of errors and warnings, and can you
add a way to configure the number of warnings ?
The 50 warnings limit is really too small.


My first problem is a mis-detection about an unused variable:

PageBot.prototype.locateElementByAugureExport = function(identifier,
> inDocument, inWindow)
> {
> var reg=new RegExp("[;]+", "g");
> var *arguments*=identifier.split(reg);
> if (*arguments*.length < 2)
> {
> throw new SeleniumError("Unknown locator: " + identifier);
> }
>     return LocateAugureExport(inDocument.body, *arguments*);
> };
>
>
> JsLint says:

> 1 "locateElementByAugureExport"(identifier, inDocument, inWindow)
>> *Unused arguments*
>>
>

The second problem is when doing consecutive catch():

function createXMLHttpRequest()
> {
> try { return new XMLHttpRequest();} *catch(e)*{}
> try { return new ActiveXObject("Msxml2.XMLHTTP");} *catch(e)*{}
> try { return new ActiveXObject("Microsoft.XMLHTTP");} *catch(e)*{}
> try { return new ActiveXObject('Msxml2.XMLHTTP.4.0');} *catch(e)*{}
>
> alert("Your browser doesn't support XMLHttpRequest");
> return null;
> }
>

JsLint says:
*Problem at line 6 character 58: 'e' is already defined.
Problem at line 7 character 61: 'e' is already defined.
Problem at line 8 character 62: 'e' is already defined.
*
JC


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

-. The argument inWindow isn't used anywhere inside the function.

- I think the catch(e) is similar like a var e = some_error_code, the catch
defines and set the e variable, so using catch in the same scope with the same
variable is something like using
var e = value1;
var e = value2;

--- On Thu, 6/4/09, Jean-Charles Meyrignac <jcmeyrignac@...> wrote:

From: Jean-Charles Meyrignac <jcmeyrignac@...>
Subject: [jslint] Problems
To: jslint_com@yahoogroups.com
Date: Thursday, June 4, 2009, 3:47 PM

















       First, could JsLint displays the number of errors and warnings, and can
you

add a way to configure the number of warnings ?

The 50 warnings limit is really too small.



My first problem is a mis-detection about an unused variable:



PageBot.prototype. locateElementByA ugureExport = function(identifier ,

> inDocument, inWindow)

> {

> var reg=new RegExp("[;]+ ", "g");

> var *arguments*= identifier. split(reg) ;

> if (*arguments* .length < 2)

> {

> throw new SeleniumError( "Unknown locator: " + identifier);

> }

>     return LocateAugureExport( inDocument. body, *arguments*) ;

> };

>

>

> JsLint says:



> 1 "locateElementByAug ureExport" (identifier, inDocument, inWindow)

>> *Unused arguments*

>>

>



The second problem is when doing consecutive catch():



function createXMLHttpReques t()

> {

> try { return new XMLHttpRequest( );} *catch(e)*{}

> try { return new ActiveXObject( "Msxml2.XMLHTTP" );} *catch(e)*{}

> try { return new ActiveXObject( "Microsoft. XMLHTTP") ;} *catch(e)*{}

> try { return new ActiveXObject( 'Msxml2.XMLHTTP. 4.0');} *catch(e)*{}

>

> alert("Your browser doesn't support XMLHttpRequest" );

> return null;

> }

>



JsLint says:

*Problem at line 6 character 58: 'e' is already defined.

Problem at line 7 character 61: 'e' is already defined.

Problem at line 8 character 62: 'e' is already defined.

*

JC



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

















	      		 Recent Activity


        1
       New Members









		 Visit Your Group





                       Search Ads
Get new customers.
List your web site
in Yahoo! Search.

                       Health Groups
for people over 40
Join people who are
staying in shape.

                       Get in Shape
on Yahoo! Groups
Find a buddy
and lose weight.




	   .

























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

On Thu, Jun 4, 2009 at 3:31 PM, Nagy Endre <forewer2000@...> wrote:
>
>
> -. The argument inWindow isn't used anywhere inside the function.
>
Ok, it seems that arguments is a reserved word.
Renaming it solves the problem.

JC

By faster do you mean faster for the interpreter to execute or faster for the
person can save characters by not using a loop?

If you mean anything but the first condition I would say you should still ban
the array constructor, because those couple extra characters a person must type
is pale in comparison to the potential harm introduced by using a method prone
to fault.  The whole point of JSLint is to solve that problem literally by
mandating style not prone to fault.

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> --- In jslint_com@yahoogroups.com, "Jakob Kruse" <kruse@> wrote:
> > Please have a look at the "JSLint Multi" widget available here:
> >
> > http://code.google.com/p/jslint-multi-widget/
> >
> > It doesn't have quite what you ask, but it does separate all the Good
> > Parts options on one preference page, and defaults to Good Parts
> > selected. It also monitors entire directory structures.
>
> Now that there is the Multi Widget, I am not going to maintain the
> original widget.
>
I don't think that Multi Widget has any way of generating a report, and the
first error is usually insufficient.

I do like Multi Widget, but it needs a way of creating a full report for a
specific file. Or maybe I'm missing something obvious.

--- In jslint_com@yahoogroups.com, Jean-Charles Meyrignac <jcmeyrignac@...>
wrote:
>
> First, could JsLint displays the number of errors and warnings, and can you
> add a way to configure the number of warnings ?
> The 50 warnings limit is really too small.

If you fixed your code, the number of warnings would drop to zero.

> > var *arguments*=identifier.split(reg);
> >> *Unused arguments*

I fixed this. Thanks. It should have complained when you used arguments as a
variable.

> The second problem is when doing consecutive catch():
>
> function createXMLHttpRequest()
> > {
> > try { return new XMLHttpRequest();} *catch(e)*{}
> > try { return new ActiveXObject("Msxml2.XMLHTTP");} *catch(e)*{}
> > try { return new ActiveXObject("Microsoft.XMLHTTP");} *catch(e)*{}
> > try { return new ActiveXObject('Msxml2.XMLHTTP.4.0');} *catch(e)*{}
> >
> > alert("Your browser doesn't support XMLHttpRequest");
> > return null;
> > }

Some browsers leak the exception variable into the function's scope so that all
of those e's are actually the same variable. I recommend that you give each
catch a unique variable name.

> >The 50 warnings limit is really too small.
> If you fixed your code, the number of warnings would drop to zero.

Sometimes I JSLint code that I didn't author, but rather inherited,
and it's nice to have all the warnings at once so I can fix them all
in one sweep without having to run JSLint multiple times (especially
when the number of warnings is in the hundreds or thousands which is
typical with code that have never been JSLinted before)

Hi

The JSLint Multi widget will have report generation facilities in the next
version. For performance reasons it always stops at the first error when loading
the list (it only needs to know if each file validates or not). Since it also
only displays the first error in the widget, a full parse was omitted initially.
I recommend using the widget in a more "real time" manner (have it running while
you edit and fix each error as the file turns red), in which case you don't
really need a report, but I acknowledge that some people would still like a
report, and will add it.

Please let me know if there's anything else you would like to see in there!

/Jakob


----- Original Message -----
From: edgauci
To: jslint_com@yahoogroups.com
Sent: Thursday, June 04, 2009 5:00 PM
Subject: [jslint] Re: Feature request





--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> --- In jslint_com@yahoogroups.com, "Jakob Kruse" <kruse@> wrote:
> > Please have a look at the "JSLint Multi" widget available here:
> >
> > http://code.google.com/p/jslint-multi-widget/
> >
> > It doesn't have quite what you ask, but it does separate all the Good
> > Parts options on one preference page, and defaults to Good Parts
> > selected. It also monitors entire directory structures.
>
> Now that there is the Multi Widget, I am not going to maintain the
> original widget.
>
I don't think that Multi Widget has any way of generating a report, and the
first error is usually insufficient.

I do like Multi Widget, but it needs a way of creating a full report for a
specific file. Or maybe I'm missing something obvious.





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

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> Suppose you need to construct a string containing n asterisks.
> It seems the fastest way to do that is
>
>     new Array(n + 1).join('*')
>

For reference, here is the way to do this with the array literal:

var foo = [];
foo.length = n + 1;
foo = foo.join('*');

Here are the different bits of code that I tested.

//Method 1
var cnt = 1000000,
     char = '*',
     str = new Array(cnt + 1).join(char);


//Method 2
var cnt = 1000000,
     char = '*',
     a = [],
     x, str;
for (x = 0; x < cnt; x += 1) {
     a[x] = char;
}
str = a.join('');


//Method 3
var cnt = 1000000,
     char = '*',
     a = [],
     x, str;
for (x = 0; x <= cnt; x += 1) {
     a[x] = '';
}
str = a.join('char');


Looking purely at execution performance, it's really a mixed bag...
In Firefox & Opera the Method 1 approach is faster.
However in IE, Safari & Chrome Methods 2 & 3 were faster.

Looking at this from a coding standpoint, I would say that Method 1 is a most
elegant bit of code.



--- In jslint_com@yahoogroups.com, "sandyhead25" <austin.cheney@...> wrote:
>
> By faster do you mean faster for the interpreter to execute or faster for the
person can save characters by not using a loop?
>
> If you mean anything but the first condition I would say you should still ban
the array constructor, because those couple extra characters a person must type
is pale in comparison to the potential harm introduced by using a method prone
to fault.  The whole point of JSLint is to solve that problem literally by
mandating style not prone to fault.
>

In some browsers the catch block has it's own scope, in others it does not...

you could try this to prove...

try {
     var x = new ActiveXObject('throw.error');
} catch (e) {
     document.write(typeof e + '<br/>');
}
document.write(typeof e + '<br/>');


--- In jslint_com@yahoogroups.com, Jean-Charles Meyrignac <jcmeyrignac@...>
wrote:
>
> First, could JsLint displays the number of errors and warnings, and can you
> add a way to configure the number of warnings ?
> The 50 warnings limit is really too small.
>
>
> My first problem is a mis-detection about an unused variable:
>
> PageBot.prototype.locateElementByAugureExport = function(identifier,
> > inDocument, inWindow)
> > {
> > var reg=new RegExp("[;]+", "g");
> > var *arguments*=identifier.split(reg);
> > if (*arguments*.length < 2)
> > {
> > throw new SeleniumError("Unknown locator: " + identifier);
> > }
> >     return LocateAugureExport(inDocument.body, *arguments*);
> > };
> >
> >
> > JsLint says:
>
> > 1 "locateElementByAugureExport"(identifier, inDocument, inWindow)
> >> *Unused arguments*
> >>
> >
>
> The second problem is when doing consecutive catch():
>
> function createXMLHttpRequest()
> > {
> > try { return new XMLHttpRequest();} *catch(e)*{}
> > try { return new ActiveXObject("Msxml2.XMLHTTP");} *catch(e)*{}
> > try { return new ActiveXObject("Microsoft.XMLHTTP");} *catch(e)*{}
> > try { return new ActiveXObject('Msxml2.XMLHTTP.4.0');} *catch(e)*{}
> >
> > alert("Your browser doesn't support XMLHttpRequest");
> > return null;
> > }
> >
>
> JsLint says:
> *Problem at line 6 character 58: 'e' is already defined.
> Problem at line 7 character 61: 'e' is already defined.
> Problem at line 8 character 62: 'e' is already defined.
> *
> JC
>
>
> [Non-text portions of this message have been removed]
>

--- In jslint_com@yahoogroups.com, "pauanyu" <pcxunlimited@...> wrote:
>
> --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@> wrote:
> >
> > Suppose you need to construct a string containing n asterisks.
> > It seems the fastest way to do that is
> >
> >     new Array(n + 1).join('*')
> >
>
> For reference, here is the way to do this with the array literal:
>
> var foo = [];
> foo.length = n + 1;
> foo = foo.join('*');
>

Nice.

String.prototype.replicate = function (n) {
     var a = [];
     a.length = n + 1;
     return a.join(this);
};
var s = '*'.replicate(10);
print(s);
var c = "cat";
var t = c.replicate(2);
print(t);

Thanks Jakob. That's excellent news.

I agree that it would be a bad idea to run a full scan for the entire list. It
would work great for me if I could get it selectively file by file.

In some cases, I don't always clean each file completely, at least not at first.
For example, I don't want to disable being warned about 'debugger' lines, but I
often want them in there for a while. Also, I don't think there's a way to
disable 'javascript url' errors, and in my humble opinion, those aren't
necessarily all evil. :)

Thanks again.

Ed

--- In jslint_com@yahoogroups.com, "Jakob Kruse" <kruse@...> wrote:
>
> Hi
>
> The JSLint Multi widget will have report generation facilities in the next
version. For performance reasons it always stops at the first error when loading
the list (it only needs to know if each file validates or not). Since it also
only displays the first error in the widget, a full parse was omitted initially.
I recommend using the widget in a more "real time" manner (have it running while
you edit and fix each error as the file turns red), in which case you don't
really need a report, but I acknowledge that some people would still like a
report, and will add it.
>
> Please let me know if there's anything else you would like to see in there!
>
> /Jakob
>
>
> ----- Original Message -----
> From: edgauci
> To: jslint_com@yahoogroups.com
> Sent: Thursday, June 04, 2009 5:00 PM
> Subject: [jslint] Re: Feature request
>
>
>
>
>
> --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@> wrote:
> >
> > --- In jslint_com@yahoogroups.com, "Jakob Kruse" <kruse@> wrote:
> > > Please have a look at the "JSLint Multi" widget available here:
> > >
> > > http://code.google.com/p/jslint-multi-widget/
> > >
> > > It doesn't have quite what you ask, but it does separate all the Good
> > > Parts options on one preference page, and defaults to Good Parts
> > > selected. It also monitors entire directory structures.
> >
> > Now that there is the Multi Widget, I am not going to maintain the
> > original widget.
> >
> I don't think that Multi Widget has any way of generating a report, and the
first error is usually insufficient.
>
> I do like Multi Widget, but it needs a way of creating a full report for a
specific file. Or maybe I'm missing something obvious.
>
>
>
>
>
> [Non-text portions of this message have been removed]
>

I've been using JSLint for several years. As a result, I've developed an
habitual JavaScript coding style which conforms to its requirements, and my code
generally passes JSLint with minimal modifications and does seem to have fewer
bugs as a result.

There is one minor feature which rubs me the wrong way, however, and repetition
does not seem to allay the irritation. It concerns the increment and decrement
operators ++ and --. On the whole, their use is frequently pernicious-- some of
the most unreadable code I've seen features tricky side effects resulting from
embedding "++" in "if" statements or assignment statements. (And then you have
to keep straight the difference between i++ and ++i.)

However, there is one case in which ++ (or --) promotes readability: when used
by itself as the increment or third part of a "for" statement. E.g., "for (i =
0; i < myArray.length; i++) { ...."
This is by far the most common for-loop form, the use of "++" in this context is
traditional, and I've found that writing " i += 1" or "i = i + 1" instead seems
only fussy and more difficult to scan visually. (Indeed, one virtue of allowing
the ++ form here would be that, e.g., "i += 2" could be reserved for cases in
which the incrementing operation is *different* from the most common case. This
surely would promote readability.)

Of course, JSLint already has an option to "disallow ++ and -- operators". But
when that option is unchecked, all uses of these operators are allowed,
including the really bad ones. What I request instead is that JSLint pass the
usage of "++" and "--" when affixed to a variable as a lone STATEMENT, not in
conditional expressions or assignment statements, and that it do this regardless
of the setting of the option. This sole usage seems safe and readable and
perhaps even efficient. And of course, In this usage, of course, you don't even
have to remember whether to put the operator on the left or the right. The vast
majority of uses thus permitted would be in "for" loops; this change would be
most useful for programming groups which wish to permit the usage of "++" as the
increment in for-loops while prohibiting its use elsewhere.

--Martin Barrett

To the extent that this is a democracy, seconded.  Kernighan and Ritchie's
decision way back when to have prefix and postfix increment and decrement
probably seemed like a good idea at the time, but as a practical matter, it only
makes real sense in the loop case (whiles and expecially fors).  Stand-alone
statements are probably OK too.

M.





________________________________
From: Martin Barrett <mbrrtt@...>
To: jslint_com@yahoogroups.com
Sent: Friday, June 5, 2009 7:24:48 AM
Subject: [jslint] Increment (++) operator


I've been using JSLint for several years. As a result, I've developed an
habitual JavaScript coding style which conforms to its requirements, and my code
generally passes JSLint with minimal modifications and does seem to have fewer
bugs as a result.

There is one minor feature which rubs me the wrong way, however, and repetition
does not seem to allay the irritation. It concerns the increment and decrement
operators ++ and --. On the whole, their use is frequently pernicious-- some of
the most unreadable code I've seen features tricky side effects resulting from
embedding "++" in "if" statements or assignment statements. (And then you have
to keep straight the difference between i++ and ++i.)

However, there is one case in which ++ (or --) promotes readability: when used
by itself as the increment or third part of a "for" statement. E.g., "for (i =
0; i < myArray.length; i++) { ...."
This is by far the most common for-loop form, the use of "++" in this context is
traditional, and I've found that writing " i += 1" or "i = i + 1" instead seems
only fussy and more difficult to scan visually. (Indeed, one virtue of allowing
the ++ form here would be that, e.g., "i += 2" could be reserved for cases in
which the incrementing operation is *different* from the most common case. This
surely would promote readability.)

Of course, JSLint already has an option to "disallow ++ and -- operators". But
when that option is unchecked, all uses of these operators are allowed,
including the really bad ones. What I request instead is that JSLint pass the
usage of "++" and "--" when affixed to a variable as a lone STATEMENT, not in
conditional expressions or assignment statements, and that it do this regardless
of the setting of the option. This sole usage seems safe and readable and
perhaps even efficient. And of course, In this usage, of course, you don't even
have to remember whether to put the operator on the left or the right. The vast
majority of uses thus permitted would be in "for" loops; this change would be
most useful for programming groups which wish to permit the usage of "++" as the
increment in for-loops while prohibiting its use elsewhere.

--Martin Barrett

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

--- In jslint_com@yahoogroups.com, "benxwhite" <ben.a.white@...> wrote:
>
> Here are the different bits of code that I tested.
>
> //Method 1
> var cnt = 1000000,
>     char = '*',
>     str = new Array(cnt + 1).join(char);
>
>
> //Method 2
> var cnt = 1000000,
>     char = '*',
>     a = [],
>     x, str;
> for (x = 0; x < cnt; x += 1) {
>     a[x] = char;
> }
> str = a.join('');
>
>
> //Method 3
> var cnt = 1000000,
>     char = '*',
>     a = [],
>     x, str;
> for (x = 0; x <= cnt; x += 1) {
>     a[x] = '';
> }
> str = a.join('char');
>
>
> Looking purely at execution performance, it's really a mixed bag...
> In Firefox & Opera the Method 1 approach is faster.
> However in IE, Safari & Chrome Methods 2 & 3 were faster.
>
> Looking at this from a coding standpoint, I would say that Method 1 is a most
elegant bit of code.
>

I'd be interested in seeing how those compare to the array literal:

var foo = [];
foo.length = n + 1;
foo = foo.join('*');

In particular, how it compares to Method 1.

Now, I fully understand the reasons behind this change, and I approve.

However, I've noticed something interesting. If you select the "Assume a
browser" option, then try to assign to a predefined global variable, you get the
"Global violation." error! Here's an example:

location = 0;
alert = 10;

If I'm reading this correctly, the "Assume a browser" mode is the same as
declaring the default global variables with var, so why is this throwing a
"Global violation." error?

--- In jslint_com@yahoogroups.com, "pauanyu" <pcxunlimited@...> wrote:
> If you select the "Assume a browser" option, then try to
> assign to a predefined global variable, you get the "Global
> violation." error! Here's an example:
>
> location = 0;
> alert = 10;
>
> If I'm reading this correctly, the "Assume a browser" mode is
> the same as declaring the default global variables with var,
> so why is this throwing a "Global violation." error?

I don't understand your question. Are you saying that you want to change those
global variables?

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> I don't understand your question. Are you saying that you want to change those
global variables?
>

Yes.

This works:

var location = 0;
var alert = 10;

But this doesn't:

location = 0;
alert = 10;

...except the "Assume a browser" mode is supposed to already supply the default
variables with the var statement, as per the JSLint Help file.

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> I don't understand your question. Are you saying that you want to change those
global variables?
>

Perhaps I was not clear enough. Allow me to quote the JSLint Help documentation:


"Some globals can be predefined for you. Select the Assume a browser (browser)
option to predefine the standard global properties that are supplied by web
browsers, such as document and alert. It has the same effect as this statement:

var alert, blur, clearInterval, clearTimeout, close, closed, confirm, console,
Debug, defaultStatus, document, event, focus, frames, getComputedStyle, history,
Image, length, location, moveBy, moveTo, name, navigator, onblur, onerror,
onfocus, onload, onresize, onunload, open, opener, opera, Option, parent, print,
prompt, resizeBy, resizeTo, screen, scroll, scrollBy, scrollTo, setInterval,
setTimeout, status, top, XMLHttpRequest;"


Let's test that statement. I will first try to change the predefined global
variables "location" and "alert":


location = 0;
alert = 1;


This fails in JSLint with the "Global violation." error. Now, let's run the same
code, but put the big var block at the beginning:


var alert, blur, clearInterval, clearTimeout, close, closed, confirm, console,
Debug, defaultStatus, document, event, focus, frames, getComputedStyle, history,
Image, length, location, moveBy, moveTo, name, navigator, onblur, onerror,
onfocus, onload, onresize, onunload, open, opener, opera, Option, parent, print,
prompt, resizeBy, resizeTo, screen, scroll, scrollBy, scrollTo, setInterval,
setTimeout, status, top, XMLHttpRequest;

location = 0;
alert = 1;


Note that JSLint does not give a "Global violation." error. As such, either
JSLint is wrong, or the documentation is wrong.

--- In jslint_com@yahoogroups.com, "pauanyu" <pcxunlimited@...> wrote:
>
> --- In jslint_com@yahoogroups.com, "benxwhite" <ben.a.white@> wrote:
> >
> > Here are the different bits of code that I tested.
> >
> > //Method 1
> > var cnt = 1000000,
> >     char = '*',
> >     str = new Array(cnt + 1).join(char);
> >
> >
> > //Method 2
> > var cnt = 1000000,
> >     char = '*',
> >     a = [],
> >     x, str;
> > for (x = 0; x < cnt; x += 1) {
> >     a[x] = char;
> > }
> > str = a.join('');
> >
> >
> > //Method 3
> > var cnt = 1000000,
> >     char = '*',
> >     a = [],
> >     x, str;
> > for (x = 0; x <= cnt; x += 1) {
> >     a[x] = '';
> > }
> > str = a.join('char');
> >
> >
> > Looking purely at execution performance, it's really a mixed bag...
> > In Firefox & Opera the Method 1 approach is faster.
> > However in IE, Safari & Chrome Methods 2 & 3 were faster.
> >
> > Looking at this from a coding standpoint, I would say that Method 1 is a
most elegant bit of code.
> >
>
> I'd be interested in seeing how those compare to the array literal:
>
> var foo = [];
> foo.length = n + 1;
> foo = foo.join('*');
>
> In particular, how it compares to Method 1.
>

//Method 4
var foo = [];
foo.length = n + 1;
foo = foo.join('*');

Method 4 compared very similar to Method 1 in speed, and actually slightly
faster. (approximately 10-40% in my tests)
It was not the fastest in every browser, but was the most consistent in
performance across browsers.

I would suggest Method 4 for best performance, and Method 1 for cleanest.

--- In jslint_com@yahoogroups.com, "benxwhite" <ben.a.white@...> wrote:
>
> //Method 4
> var foo = [];
> foo.length = n + 1;
> foo = foo.join('*');
>
> Method 4 compared very similar to Method 1 in speed, and actually slightly
faster. (approximately 10-40% in my tests)
> It was not the fastest in every browser, but was the most consistent in
performance across browsers.
>
> I would suggest Method 4 for best performance, and Method 1 for cleanest.
>

Very interesting. I find it unintuitive how using arrays to work with strings
can actually be faster than working directly with strings... yet here we are.

40% faster, you say? That's impressive, given how both appear to do exactly the
same thing. It probably has to do with the fact that "new Array" does different
things depending on what you pass to it.

JSLint does not properly ignore HTML comments:

<html>
<!--
"'
-->
</html>

Note that JSLint parses the data inside the comment, when it should be ignored.

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> I don't understand your question. Are you saying that you want to change those
global variables?
>

Here is another example of why JSLint is in error:

onblur = function () {};
onload = function () {};

Jslint group,

After long use of jslint as a web application, I just began using it with
Rhino, which is apparently ignoring my /*jslint option1 option2 ...*/
options block, shown here (typical):

/*jslint
     white: true,
     browser: true,
     undef: true,
     eqeqeq: true,
     newcap: true */

I am using:
(a) jslint.js from the JSLint and
Rhino<http://www.jslint.com/rhino/index.html>page;
(b) Rhino (1.7R1-2) freshly installed on Ubuntu 9-04; and
(c) Sun Java6 (6-13-1).

My command line is:  wjc@hoss:~/blah$ rhino jslint.js mypath/myjsfile.js

What's up with this?

Thanks in advance,
-- jedahbill


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

Maybe you got the wrong Javascript file.
Try this: http://www.jslint.com/rhino/jslint.js

java -jar path_to_rhino/js.jar http://www.jslint.com/rhino/jslint.js yourjs.js


--- In jslint_com@yahoogroups.com, William Chapman <jeddahbill@...> wrote:
>
> Jslint group,
>
> After long use of jslint as a web application, I just began using it with
> Rhino, which is apparently ignoring my /*jslint option1 option2 ...*/
> options block, shown here (typical):
>
> /*jslint
>     white: true,
>     browser: true,
>     undef: true,
>     eqeqeq: true,
>     newcap: true */
>
> I am using:
> (a) jslint.js from the JSLint and
> Rhino<http://www.jslint.com/rhino/index.html>page;
> (b) Rhino (1.7R1-2) freshly installed on Ubuntu 9-04; and
> (c) Sun Java6 (6-13-1).
>
> My command line is:  wjc@hoss:~/blah$ rhino jslint.js mypath/myjsfile.js
>
> What's up with this?
>
> Thanks in advance,
> -- jedahbill
>
>
> [Non-text portions of this message have been removed]
>

--- In jslint_com@yahoogroups.com, "christian.wirkus" <christian.wirkus@...>
wrote:
>
> Maybe you got the wrong Javascript file.
> Try this: http://www.jslint.com/rhino/jslint.js
>
> java -jar path_to_rhino/js.jar http://www.jslint.com/rhino/jslint.js yourjs.js
>
>
> --- In jslint_com@yahoogroups.com, William Chapman <jeddahbill@> wrote:
> >
> > Jslint group,
> >
> > After long use of jslint as a web application, I just began using it with
> > Rhino, which is apparently ignoring my /*jslint option1 option2 ...*/
> > options block, shown here (typical):
> >
> > /*jslint
> >     white: true,
> >     browser: true,
> >     undef: true,
> >     eqeqeq: true,
> >     newcap: true */
> >
> > I am using:
> > (a) jslint.js from the JSLint and
> > Rhino<http://www.jslint.com/rhino/index.html>page;
> > (b) Rhino (1.7R1-2) freshly installed on Ubuntu 9-04; and
> > (c) Sun Java6 (6-13-1).
> >
> > My command line is:  wjc@hoss:~/blah$ rhino jslint.js mypath/myjsfile.js
> >
> > What's up with this?
> >
> > Thanks in advance,
> > -- jedahbill
> >
> >
> > [Non-text portions of this message have been removed]
> >
>

Christian,

The url/location/resource you provided is identical to the url provided (in two
places) on the page I referenced.  So, that is the file I'm using.

Puzzled,
-- jeddahbill

I have found that JSLint complains about the forward slash in this:
/=\' /

but not in this:
/ =\'/

It seems if the first example is worthy of complaint then the second example
should be so worthy.

Here are some examples for immediate testing in the tool:
"use strict";
var x = x.replace(/=\' /g, '=\'');

"use strict";
var x = x.replace(/ =\' /g, '=\'');

--- In jslint_com@yahoogroups.com, "sandyhead25" <austin.cheney@...> wrote:
>
> I have found that JSLint complains about the forward slash in this:
> /=\' /
>
> but not in this:
> / =\'/
>
> It seems if the first example is worthy of complaint then the second
> example should be so worthy.

JSLint complains about the first case because of possible confusion with the
little used /= operator. It does not have a complaint about the second case.