<FAQENTRY> Array and hash (associative array)

[VK]

Or why I just did myArray['item01'] = "Computers" but myArray.length is
showing 0. What a hey?


There is a new trend to treat arrays and hashes as they were some
variations of the same thing. But they are not at all.

If you are doing *array", then you have to use only integer values for
array index, as it was since ALGOL.

Hash (Associative array) doesn't exists in JavaScript as a separate
programming entity. But each object inherits internal hash mechanics
from Object() constructor. In hash all keys are CDATA strings (even if
you provide a number for a key, internally it's sorted and treated as a
string).
Now some JavaScript specifics: as Array extends Object, it can be also
used as a hash. So you can do something like:

var arr = new Array();
// add to array, arr.length == 1
arr[0] = 10;

// add new property (key/value pair)
// arr.length is *not* affected !
arr['foo'] = 'JavaScript is funny sometimes';

Form values always returned to function as strings.
So in a situation like
arr[myForm.myField.value] = 4; // say myForm.myField.value == 17
JavaScript cannot determine what do you want from it: whether
you want to add new property called "17" or you want
to add an array element with index 17.

To work securely with *array* you should do something like:

var arr = new Array();
....
var i = Math.parseInteger(myForm.myFie­ld.value, 10);
if (i) {arr = quantity;}

This is with a value check.
To skip on value check you can do runtime typisation by prefixing value
with "+" (script will try to convert the following expression into a
number):

app[+myForm.myField.value] = quantity;

Then later:
for (i=0; i<arr.length; i++) {
// check arr
}


If you want to use hash (say using item names as your keys), you better
use the generic Object() constructor to have you hash free from
inherited properties.

var hash = new Object();
hash[key] = someValue;

Then later:

for (key in hash) {
// check hash[key]

 

[Richard Cornford]

Or why I just did myArray['item01'] = "Computers" but
myArray.length is showing 0. What a hey?

You mean like:-

<URL: http://www.jibbering.com/faq/#FAQ4_39 >

- and asking yourself why you expect adding (or assigning a value to) a
named property of an object to have a side effect on another of its
properties.

There is a new trend to treat arrays and hashes as
they were some variations of the same thing. But
they are not at all.

There is no trend, it has always been common for individuals to apply
inappropriate terminology to technical subjects that they don't fully
understand (even invent their own), and it is common for that action to
cause confusion/misunderstanding in others.

If you are doing *array", then you have to use only integer
values for array index, as it was since ALGOL.

That would depend on how you defined "array index". In ECMAScript 'array
index' is only a relevant concept in the specification of Array (ECMA
262 3rd edition: section 15.4) and particularly the algorithms for the
Array's special internal [[Put]] method (ECMA 262 3rd edition: section
15.4.5.1).

An 'array index' is a _string_ (P), where - ToString(ToUint32(P)) ===
P -. Thus a string representation of a positive 32 bit signed integer (0
through ((2 to the power of 32) - 1)).

Hash (Associative array) doesn't exists in JavaScript as a
separate programming entity. But each object inherits internal
hash mechanics from Object() constructor.

Javascript is not a class-based language so when inheritance is talked
about in this context it is usually inheritance through the prototype
chain that is being refereed to. Arrays have their own prototype object
but that object has a prototype of its own that is the Object.prototype
object. Thus Arrays inherit all prototyped properties of Object that are
not explicitly defined on the Array.prototype object. But the only
property that Arrays actually inherit from the Object.prototype is the -
valueOf - method, all others are masked by properties defined on
Array.prototype.

All objects, Arrays, Objects, Functions, Regular Expressions, etc, are
instances of the native ECMAScript object. Thus they all have the
characteristics of the native ECMAScritp object, but not as a result of
inheritance, they have the characteristics of that object because they
_are_ that object. One of the primary characteristics of a native
ECMAScript object is that named properties may be added to that object
and assigned values at run-time. This is where the 'hashtable' and
'associative array'-like features of javascript come from.

The significant difference between an instance of a native ECMAScript
object that is acting as an Array and one that is not is that the Array
object has had its default internal [[Put]] method replaced with a
special alternative that cares whether the property names used to write
to the properties of the object qualify as an 'array index', and
additionally acts upon the Array's - length - property, under some
circumstances, if they do.

In hash all keys are CDATA strings

CDATA is not a relevant concept in ECMAScript. String primitives are
sequences of 16 bit Unicode code points.

(even if you provide a number for a key, internally
it's sorted and treated as a string).

The algorithm for bracket notation property accessors always calls the
internal ToString function on the evaluated result of the expression
within the brackets. This is language related and happens regardless of
whether the object is an Array or not.

Now some JavaScript specifics: as Array extends Object,
it can be also used as a hash.

It can be used as a 'hash' because it _is_ a native ECMAScript object,
not because it 'extends' Object.

So you can do something like:

var arr = new Array();
// add to array, arr.length == 1
arr[0] = 10;

// add new property (key/value pair)
// arr.length is *not* affected !
arr['foo'] = 'JavaScript is funny sometimes';

Yes you can.

Form values always returned to function as strings.

Gibberish! The 'value' properties of the DOM representations of form
controls are usually of String type. Functions and return values do not
come into it.

So in a situation like
arr[myForm.myField.value] = 4; // say myForm.myField.value == 17
JavaScript cannot determine what do you want from it: whether
you want to add new property called "17" or you want
to add an array element with index 17.

Javascript knows exactly what to do with that assignment. It assigns a
value to the property of the object with the name "17", and if the
object is an Array the Array's special [[Put]] method also observes that
the property name qualifies as an 'array index' and checks to see if the
Array's length property is less than 18 and makes it 18 if it is.

To work securely with *array* you should do something like:

'Securely'? You are gibbering again.

var arr = new Array();
...
var i = Math.parseInteger(myForm.myFie­ld.value, 10);
if (i) {arr = quantity;}

This is with a value check.
To skip on value check you can do runtime typisation by
prefixing value with "+" (script will try to convert the
following expression into a number):

app[+myForm.myField.value] = quantity;

If you want to make sure that a property name used with an Array always
qualifies as an 'array index' then you would do:-

i = String( i >>> 0);

- as the internal algorithm for that operation is equivalent to -
ToString(ToUint32(i)) -, though converting the value to a string
primitive would be a bit pointless as that conversions is implicit in
the bracket notation property accessor.

But forcing unknown values into values that qualify as an 'array index'
without prior consideration of the nature of those values would be
misguided. User input should probably be verified with a regular
expression prior to its use as an array index, and then no forcing
conversion would be required.

If you want to use hash (say using item names as your keys),
you better use the generic Object() constructor to have
you hash free from inherited properties.

var hash = new Object();
hash[key] = someValue;

Then later:

for (key in hash) {
// check hash[key]

Using an Object when you don't need the overheads or side effects of the
Array's special [[Put]] method makes sense. But if you want a real
enumerable hash then implementing your own is the best option as it
avoids the potential for enumerable prototype extensions becoming
visible in for-in loops and hash keys accidentally clashing with
specification defined properties of Object objects.

Richard.

 

[VK]

Dear Richard,

FAQ 4.39 does exactly what I am fighting against: it assures that array
and hash (associative array) are the nearly the same entities, so you
just need to pay some extra attention to the syntacs. What I want to
put in is the truth that these are two very different entities you have
to deal very differently.
Also pls do not look at this as an attack onto JavaScript. It was a
BASIC of Internet, so from the beginning it needed to express the most
complicated things in the most simple way. It is not its fault that
some of its advantages became limitations 10-15 years later.

 

[John G Harris]

Or why I just did myArray['item01'] = "Computers" but myArray.length is
showing 0. What a hey?


There is a new trend to treat arrays and hashes as they were some
variations of the same thing. But they are not at all.

<snip>

It's not new round here :-(

Why the word 'hash'. Surely you mean anything that lets you put in a
property name and get out the right property value. There are several
ways of making that happen. Is a hash table really likely ?

John

 

[Dr John Stockton]

JRS: In article <[email protected]>,
dated Sat, 18 Jun 2005 07:58:48, seen in VK

Or why I just did myArray['item01'] = "Computers" but myArray.length is
showing 0. What a hey?

For an array A, A.length is given by the highest non-negative integer
index in use (add one); it is not a count of the number of elements.

That wording probably needs to be refined; but AIUI it expresses the
essence.

I'm tempted to suggest that your myArray should be a myObject.

 

[Jc]

Or why I just did myArray['item01'] = "Computers" but
myArray.length is showing 0. What a hey?

You mean like:-

<URL: http://www.jibbering.com/faq/#FAQ4_39 >

- and asking yourself why you expect adding (or assigning a value to) a
named property of an object to have a side effect on another of its
properties.

That FAQ entry does not adequately cover the misconception of how
associative arrays don't exist in javascript, nor does it talk about
the differences between using square bracket notation on an array
object versus a non-array object.

I think a new FAQ entry that discusses this in the context of the Array
object and refers to FAQ 4.39 for more info would be helpful. There's a
lot of good content in this thread that could be extracted, it would be
nice to be able to easily refer to it.

So in a situation like
arr[myForm.myField.value] = 4; // say myForm.myField.value == 17
JavaScript cannot determine what do you want from it: whether
you want to add new property called "17" or you want
to add an array element with index 17.

Javascript knows exactly what to do with that assignment. It assigns a
value to the property of the object with the name "17", and if the
object is an Array the Array's special [[Put]] method also observes that
the property name qualifies as an 'array index' and checks to see if the
Array's length property is less than 18 and makes it 18 if it is.

Yes, Javascript knows exactly what to do, but the intentions of the
developer who wrote the line of code are not clear - did he intend to
use the value as an index or a property name based on what the text of
the value is? I think that was the point.

 

[Lasse Reichstein Nielsen]

For an array A, A.length is given by the highest non-negative integer
index in use (add one);

Pedantically: The length property is *at least* one more than the
highest integer index. It can be more.

var a = [];
a.length = 1000; // length 1000 and no elements at all

it is not a count of the number of elements.

Even more not so.

/L

 

[VK]

Why the word 'hash'

To get out of the term "associative array" which:
1) confusing ("integer with a floating part" for float number - we
don't say it, do we?)
2) too long to type and to pronounce. It's asking to be abbreviated
back to "array" like "you know what kind of array I'm talking about".

Hash is used as a programming term and entity in Perl, so it's not my
invention.

 

[VK]

For an array A, A.length is given by the highest non-negative integer

index in use (add one); it is not a count of the number of elements.

It is not theoretically correct. We're having again a simplification in
the JavaScript mechnics. The things you have to do explicitly in say
Java or C++, are being done here automatically on the background.

If I do something like:

var arr = new Array();
arr[1000] = 1;

I indeed *resize* the array to hold 1000 new elements. Its length now
is 1001, it contains 1000 elements where arr[0] to arr[999] eq
*undefined*, and arr[1000] eq 1

Yes, unternally JavaScript doesn't keep 999 undefined values. Only
arr[1000] value really exists, undefined will be generated
automatically then addressing an element. But this internal mechanics
is really not of interes of end-users. They see what they see: array
length is always 1 more than the highest index, array contans length-1
elements, there unassigned elements have undefined value:

var arr = new Array();
arr[3] = 1;
for (i=0; i<arr.length; i++) {
alert((arr==undefined)? 'undefined' : arr);
}

 

[VK]

Its length now is 1001
It must be an influence of the Arabian nights stories and beer (the
latter is more probable) :-(

After having polished my math and brains, my post should be:

---------------------------------------------------------------------
It is not theoretically correct. We're having again a simplification in

the JavaScript mechnics. The things you have to do explicitly in say
Java or C++, they are being done here automatically on the background.

If I do something like:

var arr = new Array();
arr[1000] = 1;

I indeed *resize* the array to hold 1000 new elements. Its length now
is 1000, it contains 1000 elements where arr[0] to arr[998] eq
*undefined*, and arr[999] eq 1


Yes, unternally JavaScript doesn't keep 999 undefined values. Only
arr[999] value really exists, undefined will be generated
automatically then addressing an element. But this internal mechanics
is really not of interest of the end-users. They see what they should
see: each array
contains arrayObject.length elements indexed from arrayObject[0]
to arrayObject[arrayObject.length-1], there all non-initiated elements
have undefined value:

var arr = new Array();
arr[3] = 1;
for (i=0; i<arr.length; i++) {
alert((arr==undefined)? 'undefined' : arr);
}

 

[Richard Cornford]

To get out of the term "associative array" which:
1) confusing ("integer with a floating part" for float
number - we don't say it, do we?)
2) too long to type and to pronounce. It's asking to be
abbreviated back to "array" like "you know what kind of
array I'm talking about".

Hash is used as a programming term and entity in Perl, so
it's not my invention.

"Hash" would be as wrong a term to apply as "associative array". It does
have a use as a programming term and it means something specific. And
that specific something has nothing to do with any of the specified
behaviour of objects in javascript (even if the implementation _may_ be
using HashTables/Maps as the representation of those objects).

All native ECMAScript objects (Objects, Arrays, Functions, Regular
Expressions, prototypes, etc, etc) allow arbitrarily named properties to
be added to them at run-time. It doesn't need the application of a
borrowed term, that is just what any ECMAScript object _is_.

Richard.

 

[Richard Cornford]

It must be an influence of the Arabian nights stories and
beer (the latter is more probable) :-(

After having polished my math and brains, my post should be:

Apparently sober your maths are worse.

---------------------------------------------------------------------
It is not theoretically correct. We're having again a simplification
in

the JavaScript mechnics. The things you have to do explicitly in say
Java or C++, they are being done here automatically on the background.

If I do something like:

var arr = new Array();
arr[1000] = 1;

I indeed *resize* the array to hold 1000 new elements.
Its length now is 1000,
1001

it contains 1000 elements

1001 (unless you mean it contains 1000 elements equal to undefined, from
index 0 to 999).

where arr[0] to arr[998] eq *undefined*,

arr[0] to arr[998]

and arr[999] eq 1

arr[1000] == 1, arr[999] is one of the elements that was never assigned
a value.

Yes, unternally JavaScript doesn't keep 999 undefined
values. Only arr[999] value really exists,
arr[1000]

undefined will be generated
automatically then addressing an element.
But this internal mechanics
is really not of interest of the end-users.

<snip>

What exactly is an "end-user" of javascript? Surly the only sense in
which people use javascript is as a programming language (as a
programming language is the only thing that javascript is). And
javascript programmers absolutely do, and should, need to understand the
technical details of the behaviour of the language that they are using.

Without that understanding they will just find themselves wasting their
time thrashing about in the dark, attributing phenomena they observe but
don't understand to 'browser bugs' and other mystical explanations, and
achieving little of use or value to others.

Richard.

 

[Lasse Reichstein Nielsen]

Its length now is 1001

....
After having polished my math and brains, my post should be:

---------------------------------------------------------------------
It is not theoretically correct. We're having again a simplification in

the JavaScript mechnics. The things you have to do explicitly in say
Java or C++, they are being done here automatically on the background.

If I do something like:

var arr = new Array();
arr[1000] = 1;

I indeed *resize* the array to hold 1000 new elements. Its length now
is 1000, it contains 1000 elements where arr[0] to arr[998] eq
*undefined*, and arr[999] eq 1

Actually, the length property does have the value 1001, and it's
arr[1000] that equals 1.

Also, It's, pedantically, incorrect to say that the array holds 1000
(or 1001) elements. It holds exactly one enumerable property (1000), as
can be seen from:

var cnt = 0;
for (var i in arr) {
cnt ++;
}
alert(cnt); // alerts "1".

Try this to see the difference:

var arr = [];
arr[1000] = 1;
arr[500] = undefined;
// above loop gives 2, not 1
alert("500" in arr); // true
alert("501" in arr); // false

Yes, unternally JavaScript doesn't keep 999 undefined values. Only
arr[999] value really exists, undefined will be generated
automatically then addressing an element.

No, there is a difference between a property that exists and have
the value "undefined" and a property that doesn't exist. Reading
the latter will evaluate to "undefined" as well, but that's because
the language semantics says so (in particular the [[Get]] method
of objects).

There is *no* difference between arr[501] and arr[1500]. They are both
non-existing properties of the array object. The only thing that makes
you think otherwise is that one of them happens to be less than the
length property, and the other greater than.

But this internal mechanics is really not of interest of the
end-users. They see what they should see: each array contains
arrayObject.length elements indexed from arrayObject[0] to
arrayObject[arrayObject.length-1], there all non-initiated elements
have undefined value:

var arr = new Array();
arr[3] = 1;
for (i=0; i<arr.length; i++) {
alert((arr==undefined)? 'undefined' : arr);

Use "===" when comparing to undefined, or you will be surprised
Add arr[6] = null; to see.

Now try
for(i in arr) { // ...
or
alert((i in arr)?...)
and see the difference between initialized and not. Add some
arr[x]=undefined for fun.

Btw, an array literal can also leave places uninitialized:
var arr = [,,,1,,,2,,,];
should have
arr.length == 9 // but IE sucks and says 10.
and only
3 in arr && 6 in arr
be true. The remaining are undefined.

/L

 

[VK]

What exactly is an "end-user" of javascript?

Nothing like "amateur" or "beginner", I did not mean *that*. End-user
is a person who's using JavaScript for programming, but who doesn't
program JavaScript engine itself (Using C++/C#). So for him it's
important to know the difference in all contexts between say:
var myVar = 0;
and
myVar = 0
At the same time it's irrelevant to him/her at what phisical address
this var will be allocated and how the system will manage to reallocate
the memory if latter (s)he will do
myVar = "Now it will be a string";
But (s)he must know that it's possible and that it will override the
previous value.

So it's equal for him/her if that "undefined" is just created by
internal sub or indeed was kept somewhere in the memory.

P.S. I'm fixing a VBA (not mine!) with OPTIONBASE changed to 1 for all
arrays. This is the reason of my temp math disability. In my 2nd
attempt please read
arr[999] = 1;
The rest is right then.

 

[Michael Winter]

What exactly is an "end-user" of javascript?

[...] End-user is a person who's using JavaScript for programming, [...]

Then an end-user, in those terms, should understand how array operations
work, and shouldn't deceive themselves into thinking about array
resizing in memory.

As dynamic resizing is a feature that is often used, I doubt the
performance increase available from using static arrays when finding
values is worth the penalty of reallocation and wasted memory.

[snip]

I think it was agreed during the last round of discussion on
'associative arrays', that the use of such terms is fine if it aids
understanding, but it must not result in disguising what really occurs.
That is, it might help to think of certain aspects of native objects as
exhibiting the behaviour of associative arrays, but the individual must
understand that native objects are /not/ these constructs. The same
should apply to other features of ECMAScript.

Mike

 

[Richard Cornford]

Nothing like "amateur" or "beginner", I did not mean *that*.
End-user is a person who's using JavaScript for programming,
but who doesn't program JavaScript engine itself
(Using C++/C#). So for him it's important to know the
difference in all contexts between say:
var myVar = 0;
and
myVar = 0
At the same time it's irrelevant to him/her at what
phisical address this var will be allocated and how
the system will manage to reallocate the memory if
latter (s)he will do
myVar = "Now it will be a string";
But (s)he must know that it's possible and that it
will override the previous value.

Not that it is possible that it will overwrite the previous value, but
that it _will_ overwrite the previous value. This is computer
programming; pure mechanical logic with absolutely deterministic
behaviour.

Yes the programmer of javascript does not need to know anything about
the language implementation. They do need to know about the language's
specified behaviour, in as much technical detail as possible. They need
that understanding to use the language well, and they need that
understanding in order to talk about the language to others in common
trems.

So it's equal for him/her if that "undefined" is just
created by internal sub or indeed was kept somewhere
in the memory.

That is exactly the sort of thing that a javascript programmer does need
to comprehend. There is an important difference between a property that
has been created but holds the Undefined value and a property that never
has existed. The distinction is critical to understanding scope chain
Identifier resolution and the prototype chian.

Richard.

 

[VK]

We're talking around Dr John Stockton's definition that joins in one
sentence two totally different context: low-level memory management and
high-level programming entity behavior. (This is why I did not accept
it).

No, the engine doesn't fill non-initialized array members with some
placeholders. That would be a waste of memory. (Low
level)
Yes, *programmically* each array consists of (array.length) members,
where non-initialized members have undefined value. (High level)

So *programmically* my proof is here:

var arrayObject = new Array(10);
arrayObject[100] = 1;
for (i=0; i<arrayObject.length; i++) {
// 100 cicles, 100 values
}

And *programmically* the properties collection
check below doesn't proof anything, because we're
downcasting Array back to Object and studying it
from that level. So we actually do (in Java notation):
(Object)arrayObject

for (objectProperty in arrayObject) {
// 1 cicle, 1 value for (Object)arrayObject
}

JavaScript frees programmer from the "manual" memory allocation, so
*any* array can have as many members as it allowed by the language
specs. So if we want to stay on the same low-level (where array
consists only from defined members), then

var arrayObject = new Array();
really means:
var arrayObject = new Array(1073741822); // for Windows platforms

and

var arrayObject = new Array(10);
really means:
// var arrayObject = new Array(10); // silently ignored
var arrayObject = new Array(1073741822); // for Windows platforms

But do we really want to stay so low? I would propose to move on the
normal programming level, where array has (array.length) members, and
declaration Array(10) indeed means something, and one should use push()
method to nicely add new members to an array.


P.S. So much for hash

 

[Lasse Reichstein Nielsen]

We're talking around Dr John Stockton's definition that joins in one
sentence two totally different context: low-level memory management and
high-level programming entity behavior. (This is why I did not accept
it).

Difinition of what? Please include at least some context of what your
are replying to.

So *programmically* my proof is here:

var arrayObject = new Array(10);
arrayObject[100] = 1;
for (i=0; i<arrayObject.length; i++) {
// 100 cicles, 100 values
}

Proof of what. How does this differ from:

var arrayObject = new Array(10); //arrayObject.length == 10
for (i=0; i < 101; i++) {
// ... ?
}

And *programmically* the properties collection
check below doesn't proof anything, because we're
downcasting Array back to Object and studying it
from that level. So we actually do (in Java notation):
(Object)arrayObject

While I think I understand your point, comparing Javascript
to a class based language is rarely productive.

JavaScript frees programmer from the "manual" memory allocation, so
*any* array can have as many members as it allowed by the language
specs. So if we want to stay on the same low-level (where array
consists only from defined members), then

var arrayObject = new Array();
really means:
var arrayObject = new Array(1073741822); // for Windows platforms

No. The latter has arrayObject.length == 1073741822, not 0.
(And the length is an unsigned 32 bit number, so the highest index
in is
var ar = new Array();
ar[4294967294] = 1;
alert(ar.length); // 4294967295
)

var arrayObject = new Array(10);
really means:
// var arrayObject = new Array(10); // silently ignored
var arrayObject = new Array(1073741822); // for Windows platforms

You are trying to use Java arrays to understand and/or explain
Javascript arrays. However, the main difference is that in Java,
arrays have a fixed length, while in Javascript, they are dynamic.

But do we really want to stay so low? I would propose to move on the
normal programming level, where array has (array.length) members, and
declaration Array(10) indeed means something, and one should use push()
method to nicely add new members to an array.

You can do that, and most of the time it will work fine for
you. However, there will be the odd case where understanding how
arrays work, in particular that the length property only guarantees
to be at least one larger than the highest array index in use, is
necessary.

/L

 

[Richard Cornford]

We're talking around Dr John Stockton's definition that
joins in one sentence two totally different context:
low-level memory management and high-level programming
entity behavior. (This is why I did not accept it).

No, the engine doesn't fill non-initialized array members
with some placeholders. That would be a waste of memory.
(Low level)
Yes, *programmically* each array consists of (array.length)
members, where non-initialized members have undefined
value. (High level)

But Arrays do not have - array.length - members at the high level, they
have a - length - property that describes the upper limit of their
members with 'array index' names. Useful if you want to perform a loop
that will catch all of the members with 'array index' names.

So *programmically* my proof is here:

var arrayObject = new Array(10);
arrayObject[100] = 1;
for (i=0; i<arrayObject.length; i++) {
// 100 cicles, 100 values

101 cicles, 101 values. Give up the drink.

}

Proof of what? We know that the loop will catch all of the array members
with 'array index' names, and we know that non-existent property names
will result in the Array's [[Get]] method returning the Undefined value
when used in a property accessor. So we expect 101 values only one of
which is not the Undefined value, because the array only has one member
that has an 'array index' name.

And *programmically* the properties collection
check below doesn't proof anything, because we're
downcasting Array back to Object

Will you stop applying this class-based terminology to javascript. There
is no casting here. The Array is, was, and always will be, an instance
of the native ECMAScript object.

and studying it from that level.
So we actually do (in Java notation):
(Object)arrayObject

You cannot cast objects in javascript because they are
all_of_exactly_the_same_type.

for (objectProperty in arrayObject) {
// 1 cicle, 1 value for (Object)arrayObject
}

JavaScript frees programmer from the "manual" memory
allocation, so *any* array can have as many members
as it allowed by the language specs.

The specification does not impose any limits on the number of members a
native ECMAScript object may have. An Array may not nave more 'array
index' named members than can be accommodated by the definition of
'array index', but it can have as many members with non-'array index'
names as the implementation and available memory will put up with.

So if we want to stay on the same low-level (where array
consists only from defined members), then

var arrayObject = new Array();
really means:
var arrayObject = new Array(1073741822); // for Windows platforms

and

var arrayObject = new Array(10);
really means:
// var arrayObject = new Array(10); // silently ignored
var arrayObject = new Array(1073741822); // for Windows platforms

How is it that you feel it appropriate to conjure this nonsense up from
your immagenation and write it down as if it means something?

But do we really want to stay so low? I would propose to
move on the normal programming level, where array has
(array.length) members, and declaration Array(10) indeed
means something, and one should use push() method to nicely
add new members to an array.

The "normal programming level" is to attempt to understand the language
being used, not make up stories about it off the top of your head.

P.S. So much for hash

"What! drugs? I always thought your articles were a little too
inspired." (from: 'Sir Henry at Ndidi's Krall' by Vivian Stanshall
1984)

Richard.

 

[VK]

OK
JavaScript array is not really an array.
arrayObject.length keeps the highest index you managed to use so far.
It has *no* connection with the actual array's length, it's just called
so for further convenience.
Array contains as many elements as you initialized *yourselve*. If you
vant to know the real array length, you have to treat array as hash
table (map, collection) and iterate through its key/value pairs.
As the latter is the only way to treat JavaScript's array properly, it
doesn't really matter what your're doing: adding key/value pair to the
hash or adding indexed alement to the array. You're dealing with the
same object anyway.
push(), pop(), and other array methods are not needed in JavaScript.

I agree on everything stated above. Just one humble ask: please do not
put *this* to FAQ's.
Eppur si mouve!

Could we at least to mention in the FAQ's, that despite array and
associative array (map, collection, hash table) is the same thing in
JavaScript, its engine has some strange behavior:

if you do arrayObject[SomeNumber] = someValue, it counts it in
arrayObject.length
It also lets you to use standard array methods on this member. (1st
category)

if you do arrayObject[SomeString] = someValue, the engine doesn't it in
arrayObject.length
and you cannot use standard array methods on this member. (2nd
category)

Until JavaScript/JScript engine producer will rectify this obvious bug,
you need to be very attentive while putting new members in your
arrayObject.
As soon as array index is not an integer, new members falls into the
2nd category with all above listed consequences.