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

> >
> > "use strict";
> > var prop, foo;
> >
> > /*jslint forin:true */
> > for (prop in foo) {
> >     foo[prop] = "foo";
> > }
> > /*jslint forin:false */
> >

>
>
> I didn't intend for /*jslint*/ to be used this way. Mostly it just seems to
work. In this case, there was an interaction with the token lookahead and block
processing.
>
> Let me know if you find any more cases of this.
>

I always use /*jslint*/ this way. I think it is a great way to parse multiple
files or one file with several scripts from different people in it. Mostly I use
it to set indent.

My work around is to put the /*jslint forin:false */ line after the next
statement (or maybe even further away). That takes care of the lookahead issue.
It would be great if there will be a fix for that.

A small issue with that is that when changing a property and resetting it, you
basically don't know the previous state. By trial and error you can figure it
out but a nice solution would be to possibility to restore a state. (I'll post a
new message for this).

Every know and then I want to change a /*jslint*/ setting for a particular
statement. After the statement I want to restore the setting to its previous
state. It would be nice if I can restore the setting without knowing its
previous state/value (i.e. indent).

A solution would be something to push the options and afterwards pop the
options:

"use strict";
var prop, foo;

/*pushoptions*/
/*jslint forin:true*/
for (prop in foo) {
foo[prop] = "foo";
}
/*jslint forin:false*/
/*popoptions*/


I've implemented this in my pspad plugin and it works great. I would love to see
it in the official script though.

I agree with the general goal here, but I would like to request functional scope
instead of a stack. This is analogous to how "use strict" works as well.

So it would be great if I could disallow bitwise operators in general, and allow
it inside of an optimized mathematical function. What do you think of this?

Off the topic:
Are you sure bitwise operators optimize anything in Javascript?
Javascript isn't C, and the data type number is 64 bit float, not integer.


--- In jslint_com@yahoogroups.com, "aseem.kishore@..." <aseem.kishore@...>
wrote:
>
> I agree with the general goal here, but I would like to request functional
scope instead of a stack. This is analogous to how "use strict" works as well.
>
> So it would be great if I could disallow bitwise operators in general, and
allow it inside of an optimized mathematical function. What do you think of
this?
>

Fair points. I use bitwise operators in two cases currently:

- For constructing Morton numbers (mapping two dimensions to one). From
Wikipedia: "[...] a Morton number is a single integer value constructed by
interleaving the bits or digits of one or more source numbers."
http://en.wikipedia.org/wiki/Morton_number_(number_theory)

- For addressing Virtual Earth tiles (which uses a quadtree). From MSDN: "To
convert tile coordinates into a quadkey, the bits of the Y and X coordinates are
interleaved, and the result is interpreted as a base-4 number [...]"
http://msdn.microsoft.com/en-us/library/bb259689.aspx

In both cases, the functions are only called with integer numbers. You're right
that in Javascript, all numbers are technically doubles, but yet using the
bitwise operators seems to work perfectly well. I'm not sure.

I'm also not sure about whether that indeed optimizes anything. I haven't done
profiling comparisons; I'm just reusing well-known algorithms.

--- In jslint_com@yahoogroups.com, "christian.wirkus" <christian.wirkus@...>
wrote:
>
> Off the topic:
> Are you sure bitwise operators optimize anything in Javascript?
> Javascript isn't C, and the data type number is 64 bit float, not integer.
>

A lot of libraries are written inside one big, anonymous wrapper function:

(function () {
     // ...
}());

As I understand from John Resig's post on "use strict"
<http://ejohn.org/blog/ecmascript-5-strict-mode-json-and-more/>, a library
author can place "use strict" inside that wrapper function:

"A neat aspect of being able to define strict mode within a function is that you
can now define complete JavaScript libraries in a strict manner without
affecting outside code. [...] A number of libraries already use the above
technique (wrapping the whole library with an anonymous self-executing function)
and they will be able to take advantage of strict mode very easily."

(function () {
     "use strict";
     // ...
}());

But this doesn't pass JSLint, as it expects "use strict" to be at the very top,
outside the function:

"use strict";
(function () {
     // ...
}());

I'm not clear on whether this is necessarily a bad thing or not, because I don't
know what exactly it means for "use strict" to be outside of a function (in the
global scope): does it mean just that <script> (whether a file or inline) is in
strict mode, or does it mean that all Javascript globally is in strict mode?

If the latter, that's clearly something a library should avoid. But even the
former, it prevents libraries from being combined into one file (for
performance).

What are your thoughts on this? Thanks!

--- In jslint_com@yahoogroups.com, "aseem.kishore@..." <aseem.kishore@...>
wrote:
>
> A lot of libraries are written inside one big, anonymous wrapper function:
>
> (function () {
>     // ...
> }());
>
> As I understand from John Resig's post on "use strict"
<http://ejohn.org/blog/ecmascript-5-strict-mode-json-and-more/>, a library
author can place "use strict" inside that wrapper function:
>
> "A neat aspect of being able to define strict mode within a function is that
you can now define complete JavaScript libraries in a strict manner without
affecting outside code. [...] A number of libraries already use the above
technique (wrapping the whole library with an anonymous self-executing function)
and they will be able to take advantage of strict mode very easily."
>
> (function () {
>     "use strict";
>     // ...
> }());
>
> But this doesn't pass JSLint, as it expects "use strict" to be at the very
top, outside the function:


It depends on the Require "use strict";  option. You have it set, so JSLint
expects to see "use strict"; as the first line of the file. If you turn the
option off, then you can place it at the first line of a function instead.

>--- In jslint_com@yahoogroups.com, "christian.wirkus"
><christian.wirkus@...> wrote:
> > Are you sure bitwise operators optimize anything in Javascript?
> > Javascript isn't C, and the data type number is 64 bit float, not integer.

At 9/2/2009 10:24 AM, aseem.kishore@... wrote:
...
>I'm also not sure about whether that indeed optimizes anything. I
>haven't done profiling comparisons; I'm just reusing well-known algorithms.



Christian, my guess is that the reasoning behind your comment is an
assumption that Aseem would choose bit-manipulation primarily to
optimize the code on a low level. From Aseem's reply that doesn't
appear to be the case. He's using algorithms because they're
dependable and do the job without regard for how they work on a low
level, and that's interesting.

I offer the opinion that, unless a particular language structure
occurs in a loop that iterates an enormous number of times, low-level
optimization is irrelevant compared to the importance of its
usability in the high-level script.

(Can we get away with calling usability high-level or human-level
optimization?)

If a bit of syntax is easy to use, read, proofread, and modify, then
it wins. The whole purpose of high-level scripts such as JavaScript
is their human benefit only; the computers don't care, they would run
binary machine code much more quickly. But these days the chips are
so bloody fast that it takes a lot of inefficiency to make their
round trips perceptible to our own slow-poke bags of brain jelly.

Regards,

Paul
__________________________

Paul Novitski
Juniper Webcraft Ltd.
http://juniperwebcraft.com

--- In jslint_com@yahoogroups.com, "woomla" <woomla@...> wrote:
>
> Every know and then I want to change a /*jslint*/ setting for a particular
statement. After the statement I want to restore the setting to its previous
state. It would be nice if I can restore the setting without knowing its
previous state/value (i.e. indent).
>
> A solution would be something to push the options and afterwards pop the
options:
>
> "use strict";
> var prop, foo;
>
> /*pushoptions*/
> /*jslint forin:true*/
> for (prop in foo) {
> foo[prop] = "foo";
> }
> /*jslint forin:false*/
> /*popoptions*/
>
>
> I've implemented this in my pspad plugin and it works great. I would love to
see it in the official script though.
>

I had the same idea, but with different syntax:

"use strict";
var prop, foo;

/*options forin: true */
for (prop in foo) {
     foo[prop] = "foo";
}
/*end options */

Hi,

This is a little off topic, but I'm looking to integrate unit testing
into our continuous integration server. So far I've looked at
RhinoUnit (http://code.google.com/p/rhinounit/) which seems to do the
job, before I commit to this I was wondering what alternatives there
are. Ideally, I want a non browser based solution as we write IPTV
software for set top boxes that run proprietary web browsers i.e. not
Firefox, IE, Opera etc. As the apps we produce are both HTML and SVG
there can't be a reliance on either hence my interest in RhinoUnit.
I'd be interested to your thoughts.

Thanks,
Toby

@charset "UTF-8";
div {
     content: counter(foo) "." attr(bar);
}

Three things:

1) content is only supposed to be used on the :before, ::before, :after, and
::after pseudo-elements. Opera supports it on any element, in case that matters
any.

2) content can accept an "attr()" property.

2) content can accept multiple values, but JSLint expects content to only have
one. Here are the error messages:


Problem at line 3 character 27: Expected ';' and instead saw '.'.

Problem at line 3 character 31: Unrecognized style attribute 'attr'.

Problem at line 3 character 35: Expected ':' and instead saw '('.

Sure. Write what is understood best. That's what code quality is about, I think.
I just wanted to mention that bitwise operators in Javascript are not as
efficient as in other languages (because I read bitwise and optimized so close
to one another). And often are used for gaining performance only.
And I thought of something like this:
var x = 2;
x * 2 === x << 1;

If there is a context where bitwise is a clear and short solution to a problem,
use it.

Christian


--- In jslint_com@yahoogroups.com, Paul Novitski <paul@...> wrote:
>
>
> >--- In jslint_com@yahoogroups.com, "christian.wirkus"
> ><christian.wirkus@> wrote:
> > > Are you sure bitwise operators optimize anything in Javascript?
> > > Javascript isn't C, and the data type number is 64 bit float, not integer.
>
> At 9/2/2009 10:24 AM, aseem.kishore@... wrote:
> ...
> >I'm also not sure about whether that indeed optimizes anything. I
> >haven't done profiling comparisons; I'm just reusing well-known algorithms.
>
>
>
> Christian, my guess is that the reasoning behind your comment is an
> assumption that Aseem would choose bit-manipulation primarily to
> optimize the code on a low level. From Aseem's reply that doesn't
> appear to be the case. He's using algorithms because they're
> dependable and do the job without regard for how they work on a low
> level, and that's interesting.
>
> I offer the opinion that, unless a particular language structure
> occurs in a loop that iterates an enormous number of times, low-level
> optimization is irrelevant compared to the importance of its
> usability in the high-level script.
>
> (Can we get away with calling usability high-level or human-level
> optimization?)
>
> If a bit of syntax is easy to use, read, proofread, and modify, then
> it wins. The whole purpose of high-level scripts such as JavaScript
> is their human benefit only; the computers don't care, they would run
> binary machine code much more quickly. But these days the chips are
> so bloody fast that it takes a lot of inefficiency to make their
> round trips perceptible to our own slow-poke bags of brain jelly.
>
> Regards,
>
> Paul
> __________________________
>
> Paul Novitski
> Juniper Webcraft Ltd.
> http://juniperwebcraft.com
>

For what it's worth, some of the code I write does indeed run in a tight loop
many times (striving for 60 frames/sec), and low-level optimizations have proven
to help (especially in IE).

For curiosity's sake, I did some testing between bit-shifting and regular math,
and it seems bit-shifting is in fact faster for the cases I use.

Using these two functions, with i going from 0 to 50000:

     function pow2BitShifting(i) {
         var x = 1 << (i % 30);
     }

     function pow2RegularMath(i) {
         var x = Math.pow(2, (i % 30));
     }

In Firefox:

     Powers of 2 w/ bit shifting: 38 msecs
     Powers of 2 w/ regular math: 69 msecs

In IE:

     Powers of 2 w/ bit shifting: 56 msecs
     Powers of 2 w/ regular math: 107 msecs

In Chrome and Safari (nearly identical here):

     Powers of 2 w/ bit shifting: 2 msecs (!!)
     Powers of 2 w/ regular math: 16 msecs

So anyway, it's clear that using bitwise operators has its place, so to get back
to the original topic, it would be great if I could opt-in on a per-function
basis. =)

Aseem

--- In jslint_com@yahoogroups.com, "christian.wirkus" <christian.wirkus@...>
wrote:
>
> Sure. Write what is understood best. That's what code quality is about, I
think.
> I just wanted to mention that bitwise operators in Javascript are not as
efficient as in other languages (because I read bitwise and optimized so close
to one another). And often are used for gaining performance only.
> And I thought of something like this:
> var x = 2;
> x * 2 === x << 1;
>
> If there is a context where bitwise is a clear and short solution to a
problem, use it.
>
> Christian
>
>
> --- In jslint_com@yahoogroups.com, Paul Novitski <paul@> wrote:
> >
> >
> > >--- In jslint_com@yahoogroups.com, "christian.wirkus"
> > ><christian.wirkus@> wrote:
> > > > Are you sure bitwise operators optimize anything in Javascript?
> > > > Javascript isn't C, and the data type number is 64 bit float, not
integer.
> >
> > At 9/2/2009 10:24 AM, aseem.kishore@ wrote:
> > ...
> > >I'm also not sure about whether that indeed optimizes anything. I
> > >haven't done profiling comparisons; I'm just reusing well-known algorithms.
> >
> >
> >
> > Christian, my guess is that the reasoning behind your comment is an
> > assumption that Aseem would choose bit-manipulation primarily to
> > optimize the code on a low level. From Aseem's reply that doesn't
> > appear to be the case. He's using algorithms because they're
> > dependable and do the job without regard for how they work on a low
> > level, and that's interesting.
> >
> > I offer the opinion that, unless a particular language structure
> > occurs in a loop that iterates an enormous number of times, low-level
> > optimization is irrelevant compared to the importance of its
> > usability in the high-level script.
> >
> > (Can we get away with calling usability high-level or human-level
> > optimization?)
> >
> > If a bit of syntax is easy to use, read, proofread, and modify, then
> > it wins. The whole purpose of high-level scripts such as JavaScript
> > is their human benefit only; the computers don't care, they would run
> > binary machine code much more quickly. But these days the chips are
> > so bloody fast that it takes a lot of inefficiency to make their
> > round trips perceptible to our own slow-poke bags of brain jelly.
> >
> > Regards,
> >
> > Paul
> > __________________________
> >
> > Paul Novitski
> > Juniper Webcraft Ltd.
> > http://juniperwebcraft.com
> >
>

On 04/09/09 18:10, aseem.kishore@... wrote:
> For curiosity's sake, I did some testing between bit-shifting and
> regular math, and it seems bit-shifting is in fact faster for the
> cases I use.
>
> Using these two functions, with i going from 0 to 50000:
>
>     function pow2BitShifting(i) {
>         var x = 1 << (i % 30);
>     }
>
>     function pow2RegularMath(i) {
>         var x = Math.pow(2, (i % 30));
>     }

That's not really a fair comparison. The second function has to do a
lookup for 'Math', find its 'pow' property, and execute a method call to
Math.pow.

So yes, in this case, bit shifting is faster than a call to Math.pow
with base 2, but that doesn't prove that the bit operations themselves
are handled efficiently in JS.


cheers,
stefan

--- In jslint_com@yahoogroups.com, Stefan Weiss <weiss@...> wrote:
>
> On 04/09/09 18:10, aseem.kishore@... wrote:
> > For curiosity's sake, I did some testing between bit-shifting and
> > regular math, and it seems bit-shifting is in fact faster for the
> > cases I use.
> >
> > Using these two functions, with i going from 0 to 50000:
> >
> >     function pow2BitShifting(i) {
> >         var x = 1 << (i % 30);
> >     }
> >
> >     function pow2RegularMath(i) {
> >         var x = Math.pow(2, (i % 30));
> >     }
>
> That's not really a fair comparison. The second function has to do a
> lookup for 'Math', find its 'pow' property, and execute a method call to
> Math.pow.
>
> So yes, in this case, bit shifting is faster than a call to Math.pow
> with base 2, but that doesn't prove that the bit operations themselves
> are handled efficiently in JS.
>
>
> cheers,
> stefan
>

Fair point. Since that's my use case, it's a valid comparison for my scenario
(even if I cache a local reference to Math.pow first, the numbers are almost
identical, so apparently the bottleneck isn't the lookups).

But to make a more fair comparison for the purposes of the underlying question,
I changed the test to this:

     function times2BitShifting(i) {
         var x = i << 1;
     }

     function times2RegularMath(i) {
         var x = 2 * i;
     }

Again, i goes from 0 to 50000. Across all browsers, the two take essentially the
same amount of time. I sometimes just get a 1 ms difference in favor of
bit-shifting.

     Doubling w/ bit-shifting: 31
     Doubling w/ regular math: 32

So is this a fair enough comparison? Using bitwise operators seems to have no
performance penalty, and in cases where it's actually useful (e.g. powers of 2),
it's significantly [in a statistical sense] faster than regular math.

Aseem

One would think that modern JIT compiler implementations of JS would
make this whole discussion moot...

On Fri, Sep 4, 2009 at 4:01 PM,
aseem.kishore@...<aseem.kishore@...> wrote:
>
>
> --- In jslint_com@yahoogroups.com, Stefan Weiss <weiss@...> wrote:
>
>>
>> On 04/09/09 18:10, aseem.kishore@... wrote:
>> > For curiosity's sake, I did some testing between bit-shifting and
>> > regular math, and it seems bit-shifting is in fact faster for the
>> > cases I use.
>> >
>> > Using these two functions, with i going from 0 to 50000:
>> >
>> > function pow2BitShifting(i) {
>> > var x = 1 << (i % 30);
>> > }
>> >
>> > function pow2RegularMath(i) {
>> > var x = Math.pow(2, (i % 30));
>> > }
>>
>> That's not really a fair comparison. The second function has to do a
>> lookup for 'Math', find its 'pow' property, and execute a method call to
>> Math.pow.
>>
>> So yes, in this case, bit shifting is faster than a call to Math.pow
>> with base 2, but that doesn't prove that the bit operations themselves
>> are handled efficiently in JS.
>>
>>
>> cheers,
>> stefan
>>
>
> Fair point. Since that's my use case, it's a valid comparison for my
> scenario (even if I cache a local reference to Math.pow first, the numbers
> are almost identical, so apparently the bottleneck isn't the lookups).
>
> But to make a more fair comparison for the purposes of the underlying
> question, I changed the test to this:
>
> function times2BitShifting(i) {
> var x = i << 1;
> }
>
> function times2RegularMath(i) {
> var x = 2 * i;
> }
>
> Again, i goes from 0 to 50000. Across all browsers, the two take essentially
> the same amount of time. I sometimes just get a 1 ms difference in favor of
> bit-shifting.
>
> Doubling w/ bit-shifting: 31
> Doubling w/ regular math: 32
>
> So is this a fair enough comparison? Using bitwise operators seems to have
> no performance penalty, and in cases where it's actually useful (e.g. powers
> of 2), it's significantly [in a statistical sense] faster than regular math.
>
> Aseem
>
>

On 04/09/09 22:01, aseem.kishore@... wrote:
> --- In jslint_com@yahoogroups.com, Stefan Weiss <weiss@...> wrote:
>> That's not really a fair comparison. The second function has to do a
>> lookup for 'Math', find its 'pow' property, and execute a method call to
>> Math.pow.
>>
>> So yes, in this case, bit shifting is faster than a call to Math.pow
>> with base 2, but that doesn't prove that the bit operations themselves
>> are handled efficiently in JS.
>
> Fair point. Since that's my use case, it's a valid comparison for my
> scenario (even if I cache a local reference to Math.pow first, the
> numbers are almost identical, so apparently the bottleneck isn't the
> lookups).
>
> But to make a more fair comparison for the purposes of the underlying
> question, I changed the test to this:
>
>     function times2BitShifting(i) {
>         var x = i << 1;
>     }
>
>     function times2RegularMath(i) {
>         var x = 2 * i;
>     }
>
> Again, i goes from 0 to 50000. Across all browsers, the two take
> essentially the same amount of time. I sometimes just get a 1 ms
> difference in favor of bit-shifting.
>
>     Doubling w/ bit-shifting: 31
>     Doubling w/ regular math: 32
>
> So is this a fair enough comparison?

Much better, thank you. I didn't have the time to cook up a test myself
earlier, and this pretty much confirms what I expected.

> Using bitwise operators seems to have no performance penalty, and in
> cases where it's actually useful (e.g. powers of 2), it's significantly
> [in a statistical sense] faster than regular math.

I wasn't expecting to see a performance penalty. My point is that
JavaScript isn't C, and micro-optimizations using bit shifts won't bring
any real advantage over normal arithmetic operations. (They're not very
helpful in C anymore either, because modern compilers are all about
optimization, and can do this sort of thing in their sleep.) It won't
make much of a difference whether you write "i << 10" or "i * 1024".

In your specific case, the performance gain is real, and apparently it's
mostly due to avoiding the method call (unless you wrap the bit shifting
it in a function, of course).

When I'm not in a tight loop, I tend to go for the most readable
implementation, even if it means using objects and properties instead of
bit fields.


cheers,
stefan

var foo = [0,, 1,, 2,, 3];

There are times where you wish to leave particular indices of an array as
undefined. The above fails with the following errors:


Problem at line 1 character 14: Missing space after ','.

Problem at line 1 character 13: Extra comma.

Problem at line 1 character 14: Expected an identifier and instead saw ','.

Problem at line 1 character 14: Stopping, unable to continue. (100% scanned).

Fair enough. If you can think of a better way to test this, let me know. I'm
all for finding a more efficient alternative. =)
Aseem

On Fri, Sep 4, 2009 at 9:36 AM, Stefan Weiss <weiss@...> wrote:

>
>
> On 04/09/09 18:10, aseem.kishore@... <aseem.kishore%40ymail.com>wrote:
> > For curiosity's sake, I did some testing between bit-shifting and
> > regular math, and it seems bit-shifting is in fact faster for the
> > cases I use.
> >
> > Using these two functions, with i going from 0 to 50000:
> >
> > function pow2BitShifting(i) {
> > var x = 1 << (i % 30);
> > }
> >
> > function pow2RegularMath(i) {
> > var x = Math.pow(2, (i % 30));
> > }
>
> That's not really a fair comparison. The second function has to do a
> lookup for 'Math', find its 'pow' property, and execute a method call to
> Math.pow.
>
> So yes, in this case, bit shifting is faster than a call to Math.pow
> with base 2, but that doesn't prove that the bit operations themselves
> are handled efficiently in JS.
>
> cheers,
> stefan
>
>


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

--- In jslint_com@yahoogroups.com, "pauanyu" <pcxunlimited@...> wrote:
>
> var foo = [0,, 1,, 2,, 3];
>
> There are times where you wish to leave particular indices of an
> array as undefined.

This is a hazard. It is indistinguishable from the accidental inclusion of an
extra comma, which is a common typo. It also encourages the development of
tricky positional array structures when an object would serve better.

So I recommend that you explicitly include values between those commas.

At 9/5/2009 05:42 AM, pauanyu wrote:
>var foo = [0,, 1,, 2,, 3];
>
>There are times where you wish to leave particular indices of an
>array as undefined.


I imagine this was just a typo but just in case it wasn't I'll point
out that it's not the indices here that are undefined, it's the
values. The indices for the array above are consecutive integers 0-6.

Regards,

Paul
__________________________

Paul Novitski
Juniper Webcraft Ltd.
http://juniperwebcraft.com

--- In jslint_com@yahoogroups.com, "douglascrockford" <douglas@...> wrote:
>
> This is a hazard. It is indistinguishable from the accidental inclusion of an
extra comma, which is a common typo. It also encourages the development of
tricky positional array structures when an object would serve better.
>
> So I recommend that you explicitly include values between those commas.
>

Fair enough. What bothers me far more is that it stops the test! So if there's
any errors after the bad commas, you won't get to see them. I'm okay with it
throwing an error, but does it really need to completely halt any further
processing?

--- In jslint_com@yahoogroups.com, "pauanyu" <pcxunlimited@...> wrote:
>
> --- In jslint_com@yahoogroups.com, "douglascrockford" <douglas@> wrote:
> >
> > This is a hazard. It is indistinguishable from the accidental inclusion of
an extra comma, which is a common typo. It also encourages the development of
tricky positional array structures when an object would serve better.
> >
> > So I recommend that you explicitly include values between those commas.
> >
>
> Fair enough. What bothers me far more is that it stops the test! So if there's
any errors after the bad commas, you won't get to see them. I'm okay with it
throwing an error, but does it really need to completely halt any further
processing?


JSLint will now continue after an extra comma in an array literal.
But I still recommend that you fix your code.

--- In jslint_com@yahoogroups.com, Paul Novitski <paul@...> wrote:
>
> I imagine this was just a typo but just in case it wasn't I'll point
> out that it's not the indices here that are undefined, it's the
> values. The indices for the array above are consecutive integers 0-6.
>
> Regards,
>
> Paul
> __________________________
>
> Paul Novitski
> Juniper Webcraft Ltd.
> http://juniperwebcraft.com
>

You are quite right. I meant to say "There are times where you wish to leave the
value of particular indices of an array as undefined."

--- In jslint_com@yahoogroups.com, "douglascrockford" <douglas@...> wrote:
>
> JSLint will now continue after an extra comma in an array literal.
> But I still recommend that you fix your code.
>

Thank you.

Actually, I would never write such garrish code (normally). Allow me to explain
my use case (and how I found out about this):

I have a function that converts a string into an array. For instance, the string
"[0, 1, 2, 3, 4]" gets converted into the array [0, 1, 2, 3, 4].

It needs to be able to handle a variety of situations; strings, booleans,
numbers, etc. So I wrote a bunch of unit tests to verify that it is working
properly. They have already helped me catch a couple regressions.

The goal of the function was to convert the string as accurately as possible, so
if you pass in the string "[,,,]" you should get back the array [,,,]. I had a
unit test that verified that commas in the string would properly get converted
to commas in the array.

When running these unit tests in JSLint, I stumbled upon the error, hence this
post.

/*jslint browser: true */
escape("xyz");

Error:
Implied global: escape 2

--- In jslint_com@yahoogroups.com, "christian.wirkus" <christian.wirkus@...>
wrote:
>
> /*jslint browser: true */
> escape("xyz");
>
> Error:
> Implied global: escape 2

The global escape function is not a creature of the browser. It was a creature
of JavaScript, but was deprecated because it produces incorrect results for
non-ASCII characters. You should use encodeURI or encodeURIComponent instead.

--- In jslint_com@yahoogroups.com, "douglascrockford" <douglas@...> wrote:
>
> --- In jslint_com@yahoogroups.com, "christian.wirkus" <christian.wirkus@>
wrote:
> >
> > /*jslint browser: true */
> > escape("xyz");
> >
> > Error:
> > Implied global: escape 2
>
> The global escape function is not a creature of the browser. It was a creature
of JavaScript, but was deprecated because it produces incorrect results for
non-ASCII characters. You should use encodeURI or encodeURIComponent instead.
>

Oh, thanks.

If a script is entered into JSLint.com[1] containing a destructuring
assignment[2], JSLint gives a strange error message[3] that has little or
nothing to do with the actual cause of the error, then dies -- i.e. doesn't
produce any more results. The message appears to indicate a problem in the
script at that position, but is I think actually an error message from JSLint
itself.

I guess I'd like to see one of two things: either JSLint supporting this
assignment syntax (nice, but will take a while, probably); or JSLint at any rate
not crashing on it.

Test script:
/*jslint white: true, onevar: true, browser: true, undef: true, eqeqeq: true,
indent: 2 */
/*globals window */
/*members alert, ceil, random */

function fib(n) {
   var p1 = 1, p2 = 1, i;

   for (i = 0; i < n; i++) {
     // Destructuring assignment (see e.g.
https://developer.mozilla.org/en/New_in_JavaScript_1.7#Destructuring_assignment)
     [p2, p1] = [p1, p2 + p1];
   }
   return p2;
}

function echo(s) {
   if (window && typeof window.alert === "function") {
     window.alert(s);
   }
   else if (WScript && typeof WScript.Echo === "function") {
     WScript.Echo(s);
   } else { /* Oh well! */ }
}

var n = Math.ceil(Math.random() * 100);
echo("fib(" + n + ") = " + fib(n));



[1]  Tested with 2009-08-31 edition.
[2]  See e.g.
https://developer.mozilla.org/en/New_in_JavaScript_1.7#Destructuring_assignment
[3] Specifically, "left.left is undefined", presented as though a standard
problem message corresponding to a flaw in the script.

I want to recheck some bits of older code against the everchanging good parts,
and for I use rhino-jslint, I have to change the jslint-options-string again and
again.
Would it be possible to create an option like this?:
/*jslint goodparts: true*/

And to use it in combination?
/*jslint goodparts: true, browser: true*/

Christian