I know there is not compare function, but was not this good enough?
for(var i =1, length = array.length, n; i < length;++i){if(-1<(n = array.indexOf(array[i -1], i))){
a.splice(n,1);--length;--i;}};
an optimized fast performances version could avoid the inline splice and store those index to discard (splice could cost a lot) in order to push only certain indexes (not duplicated)
Interesting! I wouldn’t have thought to use indexOf() or splice() since I just assumed those were expensive operations. I see you’ve minimized the impact of scanning the array by using the second argument for indexOf(). Clever. Some day I’ll do some real benchmarking to see what works best.
indexOf is unfortunately expensive only in IE where it’s not native while splice could be expensive but above for loop is something extremely easy to maintain (5 line of code that should just work).
On the other hand I am using on up to two native methods against sort + forEach + map + push + all callbacks involved and executed for each index so I am kinda sure mine will perform 2 up to 5 times faster (in IE as example just sort is expensive).
Finally, if the goal is to make something portable for every case, objects included, with mine you are sure about unique primitives/instances so it depends what you need (if you need just to compare a single object property, mine won’t make sense)
Regards
Joking aside, though, you can configure it so it only spits out errors and warnings that you do care about, which is what I respect about JSLint; not forcing itself upon the user with self-righteous demands. While I do agree with some of the points you’ve raised (especially using clauses like the ‘==’ you mentioned earlier), this tool is draconic for a reason – there’s a myriad of developers who come from all sorts of backgrounds, and JSLint helps with the most common eyesores and no-nos.
While I agree, this tends to align itself with the way Apple treats its users (lock ‘em out since they don’t know what they’re doing), but the fact that with a little configuration you can get only “your” good parts out of the parser, which makes it an excellent tool.
Hey Krof, thanks for the info about the configuration options. I used the online version at http://jslint.com/. It’s got only a few configuration options. I imagine if I download and run it locally, it might have options for some of the other items I encountered.
For instance, it also didn’t like that I used unescaped curly braces in my regular expressions or that I used escaped line endings in my strings. I imagine those might break some of the dumber minification tools.
I didn’t see any options for those on the site. I think they should put some text in the options to let users know. Something like “Want more options to configure jslint? Download it for full control.” Or something like that.
I always had trouble with minification tools whenever I skipped the curly braces in IF, so I started insisting my team use them. Maybe the tools have gotten smarter since then? The side benefit, of course, was that grouping/nesting problems (which plagued one colleague in particular) magically went away. heh.
Not sure about those points; but you can always address those issues on the JSLint group list at http://tech.groups.yahoo.com/group/jslint_com/ – Crockford personally oversees all the suggestions and usually integrates patches, fixes and enhancements in a matter of days.
Gotta hand it to Doug, he’s sure streamlined the work he does on JSLint.
I’m not sure what specs you were looking at but ECMAScript defines the following syntax:
if ( Expression ) Statement else Statement
if ( Expression ) Statement
{…} (a block) is technically a statement in itself (a statement that contains statements). I tend to use blocks because, oddly, I find them more readable.
With the variable declaring issue, I always opt for declaring ALL variables at the top of the function — you may as well, considering that they’re all going to be “hoisted” there anyway…
I’ve never had to use obj == null … most of the time this is exactly the same as just “obj” in a boolean context. (i.e. if(obj){…} or !!obj).
When you intend to do that things that JSLint thinks are wrong, you can indicate it in the code and the tool will not warn you:
var test = 0;
/*jslint: eqeqeq: false */
if (test == false) { /*jslint: eqeqeq: true */
doStuff();
}
/*jslint plusplus: false */
for (test = 0; test < 5; ++test) { /*jslint plusplus: true */
doMoreStuff()
}
Of course, there doesn't seem to be an option to allow == null – since null and undefined are distinct values, "typeof(test) === 'undefined' || test === null" indicates to the next programmer (with fewer bytes than a comment) that you know precisely what your variable should contain.
Hey John, Nice post.
You might have observed during the time we interacted – I too write my code with braces, whenever possible. I still feel it is easier to read code that way.
BTW, you did nail the IE-only bug right?
Heh, the old Netscape specs are kinda loose. In a recent blog post, Andrea Giammarchi reminded me that if (x == null) is the same as writing if (x == null || x == undefined) (and also removes your responsibility of ensuring that undefined is really undefined.) Once in a while I’ll use that if I don’t care about whether the next developer understands Javascript’s many coercion nuances.
You’re certainly right about just using if (obj) some times. If the docmentation clearly states that we’re expecting an object for a parameter (or something else that won’t coerce ambiguously), I’ll use that. Until ES5, it’s by far the fastest and lightest way to detect missing args — and, imho, the easiest to read.
@h3
That’s not really bounce, but more like threshold. I you press a key less then 15ms and it doesnt register the keypress then it’s a threshold problem, or whatever they call it. Bounce refers to multiple contiguous events reduced to a same event. Your problem is one (or more) event(s) reduced to zero events
IMHO!
Hey John, I appreciate you for your help!!
I Think You are very clever. Thankyou
Very helpful, thanks!
Another great post as usual. Had checked out prototype.js sometime back but never dojo. Now that you mention it, will surely try my hands on it.
I know there is not compare function, but was not this good enough?
an optimized fast performances version could avoid the inline splice and store those index to discard (splice could cost a lot) in order to push only certain indexes (not duplicated)
Interesting! I wouldn’t have thought to use indexOf() or splice() since I just assumed those were expensive operations. I see you’ve minimized the impact of scanning the array by using the second argument for indexOf(). Clever. Some day I’ll do some real benchmarking to see what works best.
indexOf is unfortunately expensive only in IE where it’s not native while splice could be expensive but above for loop is something extremely easy to maintain (5 line of code that should just work).
On the other hand I am using on up to two native methods against sort + forEach + map + push + all callbacks involved and executed for each index so I am kinda sure mine will perform 2 up to 5 times faster (in IE as example just sort is expensive).
Finally, if the goal is to make something portable for every case, objects included, with mine you are sure about unique primitives/instances so it depends what you need (if you need just to compare a single object property, mine won’t make sense)
Regards
Why not use the native filter for primitives?
I understand this won’t work for complex objects and if you want them sorted, you’ll have to do that afterwards.
It can actually be just a little faster than that using the third parameter::
It can actually be just a little faster than that using the third parameter:
(Corrected the variable names)
Is it “just a little faster” because the variable,
ary, is lower in the scope chain thanarray? Or is there some special magic here?Well, looks like someone’s feelings got hurt.
Joking aside, though, you can configure it so it only spits out errors and warnings that you do care about, which is what I respect about JSLint; not forcing itself upon the user with self-righteous demands. While I do agree with some of the points you’ve raised (especially using clauses like the ‘==’ you mentioned earlier), this tool is draconic for a reason – there’s a myriad of developers who come from all sorts of backgrounds, and JSLint helps with the most common eyesores and no-nos.
While I agree, this tends to align itself with the way Apple treats its users (lock ‘em out since they don’t know what they’re doing), but the fact that with a little configuration you can get only “your” good parts out of the parser, which makes it an excellent tool.
Hey Krof, thanks for the info about the configuration options. I used the online version at http://jslint.com/. It’s got only a few configuration options. I imagine if I download and run it locally, it might have options for some of the other items I encountered.
For instance, it also didn’t like that I used unescaped curly braces in my regular expressions or that I used escaped line endings in my strings. I imagine those might break some of the dumber minification tools.
I didn’t see any options for those on the site. I think they should put some text in the options to let users know. Something like “Want more options to configure jslint? Download it for full control.” Or something like that.
I always had trouble with minification tools whenever I skipped the curly braces in IF, so I started insisting my team use them. Maybe the tools have gotten smarter since then? The side benefit, of course, was that grouping/nesting problems (which plagued one colleague in particular) magically went away. heh.
PS Old Rasputin FTW!
Not sure about those points; but you can always address those issues on the JSLint group list at http://tech.groups.yahoo.com/group/jslint_com/ – Crockford personally oversees all the suggestions and usually integrates patches, fixes and enhancements in a matter of days.
Gotta hand it to Doug, he’s sure streamlined the work he does on JSLint.
I’m not sure what specs you were looking at but ECMAScript defines the following syntax:
if ( Expression ) Statement else Statement
if ( Expression ) Statement
{…} (a block) is technically a statement in itself (a statement that contains statements). I tend to use blocks because, oddly, I find them more readable.
With the variable declaring issue, I always opt for declaring ALL variables at the top of the function — you may as well, considering that they’re all going to be “hoisted” there anyway…
I’ve never had to use obj == null … most of the time this is exactly the same as just “obj” in a boolean context. (i.e. if(obj){…} or !!obj).
When you intend to do that things that JSLint thinks are wrong, you can indicate it in the code and the tool will not warn you:
var test = 0;
/*jslint: eqeqeq: false */
if (test == false) { /*jslint: eqeqeq: true */
doStuff();
}
/*jslint plusplus: false */
for (test = 0; test < 5; ++test) { /*jslint plusplus: true */
doMoreStuff()
}
Of course, there doesn't seem to be an option to allow == null – since null and undefined are distinct values, "typeof(test) === 'undefined' || test === null" indicates to the next programmer (with fewer bytes than a comment) that you know precisely what your variable should contain.
Definitely agree with #3 – if you post your issue on http://tech.groups.yahoo.com/group/jslint_com/ Douglas usually responds very quickly.
Hey John, Nice post.
You might have observed during the time we interacted – I too write my code with braces, whenever possible. I still feel it is easier to read code that way.
BTW, you did nail the IE-only bug right?
Ok, so like 95% of the world insists on braces. Sheesh. (Including at least one minifier — although I haven’t encountered it.)
So now I’m trying to use braces for one-liners. Maybe I’ll get used to it.
Eventually.
(@Pankaj, yah, I found the bug the old-fashioned way: alert() statements!)
Hey James,
Heh, the old Netscape specs are kinda loose. In a recent blog post, Andrea Giammarchi reminded me that
if (x == null)is the same as writingif (x == null || x == undefined)(and also removes your responsibility of ensuring that undefined is really undefined.) Once in a while I’ll use that if I don’t care about whether the next developer understands Javascript’s many coercion nuances.You’re certainly right about just using
if (obj)some times. If the docmentation clearly states that we’re expecting an object for a parameter (or something else that won’t coerce ambiguously), I’ll use that. Until ES5, it’s by far the fastest and lightest way to detect missing args — and, imho, the easiest to read.@h3
That’s not really bounce, but more like threshold. I you press a key less then 15ms and it doesnt register the keypress then it’s a threshold problem, or whatever they call it. Bounce refers to multiple contiguous events reduced to a same event. Your problem is one (or more) event(s) reduced to zero events
IMHO!
Hey John,
Really liked your Cujo project, saw presentation. Can’t wait for its release.