Array constructor or literal

I've been taking a look at Douglas Crockford's JSLint.

One of the conventions that it expects is that arrays be created using
literal notation
var arr1 = [];

as opposed to using a constructor
var arr2 = new Array();

I've been a-googling, but the best reason for this that I can find is
"because it's not necessary to use a constructor".

I'm wondering:

1) Is there a way to tell the difference between arr1 and arr2 as
defined above, once they've been defined?

2) Is there anything, beyond stylstic reasons, to prefer one method over
another?


I've no problem against JSLint choosing a specific convention and
applying it. I'm just wondering if there is anything *beyond* convention
to speak in favour of literal over constructor notation.

Dan Rumney <danrumney (AT) warpmail (DOT) net> writes:

I've been taking a look at Douglas Crockford's JSLint.

One of the conventions that it expects is that arrays be created using
literal notation
var arr1 = [];

as opposed to using a constructor
var arr2 = new Array();

I've been a-googling, but the best reason for this that I can find is
"because it's not necessary to use a constructor".

I'm wondering:

1) Is there a way to tell the difference between arr1 and arr2 as
defined above, once they've been defined?

No, unless you override the default Array constructor, which you
probably shouldn't.

Tthe "Compatibility Between ES3 and Proposed ES4" document discusses
some of this, see section 1.4 of:

http://www.ecmascript.org/es4/spec/i...tibilities.pdf

2) Is there anything, beyond stylstic reasons, to prefer one method
over another?

Style is important :-) What would you rather see:

var aoo = new Array( new Array(),
new Array( 1, 2, new Array() ) );

Or

var aoo = [ [],
[ 1, 2, [] ] ];

I definitely prefer the second. Array literals remove a lot of clutter
from the code. And if you look at object literals vs new Object() the
difference is even bigger.

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

On Jun 12, 2:48 pm, Dan Rumney wrote:

I've been taking a look at Douglas Crockford's JSLint.

One of the conventions that it expects is that arrays be
created using literal notation
var arr1 = [];

as opposed to using a constructor
var arr2 = new Array();

I've been a-googling, but the best reason for this that I can
find is "because it's not necessary to use a constructor".

I'm wondering:

1) Is there a way to tell the difference between arr1 and
arr2 as defined above, once they've been defined?

None.

2) Is there anything, beyond stylstic reasons, to prefer one
method over another?

One is shorter than the other, while neither are unclear.

I've no problem against JSLint choosing a specific convention
and applying it. I'm just wondering if there is anything
*beyond* convention to speak in favour of literal over
constructor notation.

One is shorter than the other, while neither are unclear. That is
probably all.

Dan Rumney <danrumney (AT) warpmail (DOT) net> wrote:

I've no problem against JSLint choosing a specific convention and
applying it. I'm just wondering if there is anything *beyond* convention
to speak in favour of literal over constructor notation.

I don't have a problem with this particular convention. The only time I can

think where it would be important to use the Array constructor explicitly
would be if you had a function which created an object and the type of the
object varied somehow. In that case though you'ld be calling 'new theType
()' rather than 'new Array()' so jslint wouldn't flag it anyway, and I
can't think of a concrete example where you'ld do that.

I do have issues with some of the other warnings generated by jslint which
is why I produced a modified version that lets you ignore particular error
messages if you don't like them.

My modified jslint is at:
http://codespeak.net/svn/kupu/trunk/kupu/jslint.js if you are interested.
The same version works with either Rhino or Microsoft's scripting engine.

Also in the same subversion folder lint.py is a frontend to run jslint over
a lot of javascript files, every time they've changed (you can't use make
because there's no output file) and jslint.opts is the set of command line
options I use for that particular project. I suppressed things like
'Indentifier already declared' and 'Unnecessary semicolon' because I happen
to prefer to always prefix my loop variables with 'var', and I also prefer
to not have to look back through maybe hundreds of lines of code to
determine when a semi-colon is not required.

--
Duncan Booth http://kupuguy.blogspot.com

Duncan Booth wrote:

Dan Rumney <danrumney (AT) warpmail (DOT) net> wrote:

I've no problem against JSLint choosing a specific convention and
applying it. I'm just wondering if there is anything *beyond* convention
to speak in favour of literal over constructor notation.

I do have issues with some of the other warnings generated by jslint which
is why I produced a modified version that lets you ignore particular error
messages if you don't like them.

I think it's wrong for it to be called jslint when really it should be
called jscrockford. It's something that he wrote that highlights
anything that doesn't meet his particular coding standards. They're not
rules, just preferred styles. Not that I'm saying there's anything wrong
with the things it complains about, but they're certainly not all
errors. I tried it once and didn't want to change my code in the way
necessary to make it happy.

As I recall from my C days, lint was more like a pre-compiler that would
tell you what real errors/warnings you have in your code, rather than
how it's not suiting one person's style choices. It was used because it
was quicker than running the full compiler.

On Jun 12, 7:35 pm, Stevo <n... (AT) mail (DOT) invalid> wrote:

I think it's wrong for it to be called jslint when really it should be
called jscrockford.

:-) Fully sustained. jslint as it is right now is just like some C
checker which would mark missing closing brackets - and at the same
time would issue errors for each opening bracket placed on the same
line as the method name (or below it). So it is a rather strong
cocktail of a code checker and a particular pretty-print enforcer.
Still the author is fairly fair about it:
http://tech.groups.yahoo.com/group/jslint_com/
"Warning: JSLint will hurt your feelings."
Moreover no one is forcing to use JSLint as some "final authoritative
validity" tool. In this aspect W3C HTML Validator is much more
damaging.

Concerning the OP's question:
there is not a damn difference between Array and [] - they are equal.
One plus of Array is that it allows to set the initial size of the
array without members' initialization:
var a = new Array(1000);
it may be useful if one needs to take extra steps on array elements
above or below the initial size.

One plus of [] is that it makes the code uniformly looking with JSON
data. With Mr. Crockford being the author of JSON, this is - I guess -
the core of the JSLint's "bracket obsession" :-)

VK wrote:

On Jun 12, 7:35 pm, Stevo <n... (AT) mail (DOT) invalid> wrote:
I think it's wrong for it to be called jslint when really it should be
called jscrockford.

:-) Fully sustained. jslint as it is right now is just like some C
checker which would mark missing closing brackets - and at the same
time would issue errors for each opening bracket placed on the same
line as the method name (or below it). So it is a rather strong
cocktail of a code checker and a particular pretty-print enforcer.
Still the author is fairly fair about it:
http://tech.groups.yahoo.com/group/jslint_com/
"Warning: JSLint will hurt your feelings."
Moreover no one is forcing to use JSLint as some "final authoritative
validity" tool.

Absolutely. I hope my message didn't come across excessively negatively
to JSLint. Didn't meant it to.

One plus of [] is that it makes the code uniformly looking with JSON
data. With Mr. Crockford being the author of JSON, this is - I guess -
the core of the JSLint's "bracket obsession" :-)

I love the square brackets. I remember the day I did a global replace of
new Array() with [] and saw the file size reduction I'd like to say
it was 4 years ago I did that, but it was only about 6 months ago ;-)

Dan Rumney wrote:

I've been taking a look at Douglas Crockford's JSLint.

One of the conventions that it expects is that arrays be created using
literal notation
var arr1 = [];

as opposed to using a constructor
var arr2 = new Array();

The bracket notation is preferred always. It is smaller and more consistent.

[] and new Array() do the same thing.

[1, 2] and new Array(1, 2) do the same thing.

[1] and new Array(1) do not do the same thing.

[undefined] and new Array(1) do extremely similar things.

http://www.JSLint.com/

Douglas Crockford wrote:
[snip]

The bracket notation is preferred always. It is smaller and more
consistent.

[] and new Array() do the same thing.

[1, 2] and new Array(1, 2) do the same thing.

[1] and new Array(1) do not do the same thing.

[undefined] and new Array(1) do extremely similar things.

http://www.JSLint.com/

I'd been wooed by Joost's nested arrays argument, but the example you
give here about consistency is the clincher.

Personally, I'd be unlikely to mix
Array(size)
and
Array(contents)

but I can see that being a general concern. In my opinion, that's a
nasty piece of overloading.

For what it's worth, I'm not really compelled by arguments of script
size. I'm sure there are very *specific* cases where it makes a
difference, but we're talking about 9 bytes saved per array creation.
At 256kbps, this is only about 280 microseconds per array creation.

Still, it's not the function of Usenet to compel me to believe anything.
I appreciate JSLint for what it is: a very useful tool to act as a check
and balanced against my own coding vagaries... Thanks Douglas!

Dan Rumney wrote:

I've been taking a look at Douglas Crockford's JSLint.

One of the conventions that it expects is that arrays be created using
literal notation
var arr1 = [];

as opposed to using a constructor
var arr2 = new Array();

I've been a-googling, but the best reason for this that I can find is
"because it's not necessary to use a constructor".

I'm wondering:

1) Is there a way to tell the difference between arr1 and arr2 as
defined above, once they've been defined?

There isn't, both return a reference to an Array object. Array() called as
a factory also does:

var arr2 = Array(...);

(see ES3 Final, 15.4.1)

2) Is there anything, beyond stylstic reasons, to prefer one method over
another?

Inconsistencies in ECMAScript implementations would cause you to prefer the
initializer over the constructor/factory call (as Douglas pointed out).

Incompatibilities between ECMAScript implementations would cause you to
prefer the constructor/factory call over the initializer; those are:

1. Only JavaScript supports a trailing comma with the initializer.
2. The initializer requires JavaScript 1.3, JScript 2.0, or an
implementation of ECMAScript Ed. 3. The factory/constructor
call only requires JavaScript 1.1, JScript 2.0, or an implementation
of ECMAscript Ed. 1.

Obviously point 2 is of little importance nowadays. (The next revision of
the ECMAScript Support Matrix at <http://PointedEars.de/scripts/es-matrix/>
will probably mark this language feature as "safe to use (without feature
test)". I have yet to test more implementations to be sure.)

I would presume, but I have not tested yet, that there is also a slight
performance loss when using the constructor/factory instead of the
initializer because of stack operations.


PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7 (AT) news (DOT) demon.co.uk>