VK said:
RobG wrote:
As you can see, despite that mechanically (on the memory level)
we have only two elements in the entire arrayOne (arrayOne[0]
and arrayOne[100]), programmatically we have one continuos array
of 101 element in total:
"foo", undefined, undefined, ... , undefined, "bar"
Which is your interpretation of things.
Sorry, and what is *your* interpretation of things?
You just stated (you were just forced to): "elements from
... to...". Because it's right: array consists of the number
of elements length-1 *when we are using array as array*.
In the particular for array methods where are always
0...length-1 elements in array. If you have another
interpretation of "things" then state it.
The Array methods; slice, reverse, concat, shift and unshift have (ECMA
262) specified behaviour that masks the nature of their Array object.
They each generate a sequence of numeric values limited by the Array's
length property and then use those numeric values, converted into
strings, with the Array's [[Get]] method to acquire a value and then use
the Array's [[Put]] method to assign that value to a property of an
Array.
Because the [[Get]] method of ECMAScritp objects (and so Arrays) returns
Undefined when the object does not have a property with the
corresponding name, but the [[Put]] method creates a property with the
corresponding name when there is no pre-existing property, the
application of an array method may produce a result that is
significantly different from the original Array.
A good example is the - reverse - method (as it acts upon the array
itself instead of producing an array result).
Using an ECMA 262 conforming browser such as Mozilla:-
var a = [];
a[0] = 'foo';
a[99] = 'bar'
- creates and array with a length property of 100, and counting its
defined elements with:-
var count = 0;
for(var prop in a){
++count;
}
alert(count);
- produces a count of 2. But then applying:-
a.reverse();
- and repeating:-
var count = 0;
for(var prop in a){
++count;
}
alert(count);
- produces a count of 100. The act of calling [[Get]] with each number
in the range 0 to (array.length-1) and then calling [[Put]] has created
all of those properties, regardless of whether they existed before the
call to reverse.
Thus, if the Array methods make the array look as if it is a continuous
sequence of properties instead of an object with possibly fewer existing
'array index' properties than 0 to (array.length-1) would accommodate,
that may be because the specified action of the methods is to create an
object that does actually have all of those properties. The results of
those method calls imply nothing about the objects on which they are
called.
In ECMAScript we can create, and work with, an object such as:-
var a = [];
a[4294967294] = 'foo';
- without flooding the entire OS memory map, precisely because the
underlying object does not have 4294967295 existing properties. And we
can enumerate the properties of that object with a for/in loop and
expect to see the result in our lifetime. We can also be sure that
calling the - reverse - method of that object in an ECMA 262 conforming
environment would be a somewhat foolish thing to do.
There is a general concept of what an 'array' is, stressing an ordered
arrangement, and a concept more specific to computing in general that
places more stress on the subscript/index. ECMAScript demonstrates that
the concept can be satisfied by many structures. For practical purposes
it is only necessary that the 'length' of an array (or combination of
its upper and lower bounds, where they may both be variable) expresses
the limits of its contents, and that accessing items within those limits
always has a consistent outcome.
Because the ECMAScript Array's special [[Put]] method may interact with
its - length - property upon assignment operations, and the native
ECMAScript object's [[Get]] method always returns a value (which may be
the Undefined value, if that is the value of the property and whenever
the property does not exist) we have an object that may be treated as a
continuous sequence of ordered storage locations limited by the arrays
length without any need for it to actually possess such a sequence of
storage locations. The general concept is satisfied and can be used in
designing code to be implemented in ECMAScript.
However, while the general concept of an array can be employed in script
authoring it can only benefit the author of such scripts to understand
the nature of the object that they are using. Take Kevin Newman's code
as an example. If the ECMAScript Array implementation really was a
continuos sequence of indexed storage locations then his implementation
would be objectively bad (as it must get slower the more it operated,
and it must consume progressively more memory as the Array got longer).
As it is his implementation is fine from a practical point of view. The
worst that can be said of it is that it doesn't 'feel' right to be using
an Array just for its self-incrementing - length - property (very much a
matter of opinion).
It is not in satisfying the general concept of 'array' that the
ECMAScript author needs to understand the object being used, it is when
they go outside of that concept. There is the use of an Array as an
'associative array' and the oft repeated question as to why the
assignment of a non-'array index' property does not affect the Array's
length. There is the employment of an array as a repository for
name/value pairs that can also be looped over, where the named
properties store integer values that refer to the real vales stored
under 'array index' property names. And host of other applications of
Arrays that can only be properly explained by an appreciation of what an
ECMAScript Array really is.
So far your interpretation as I get it could be summarized
this way: "Array consists of length-1 elements which we can
see clearly by applying array methods. Array consists of only
defined elements and it has numeric property 'length'."
With all my respect, it's not an interpretation, but a loosely
made aporia.
Your unfounded opinion that the Array methods might demonstrate a
non-sparseness in ECMAScript arrays is at the root of your perception of
a contradiction. The object that is an ECMAScript array is quite capable
of being used as if it was a continuos sequence of indexed storage
locations without actually being a continuos sequence of storage
locations. ECMA 262 explains both how and why Arrays behave in the way
they do, both in satisfying the general concept of an 'array' and in
providing behaviour that is well outside of that concept.
Richard.
