VK said:
I summarized all points in this article:
<
http://www.geocities.com/schools_ring/ArrayAndHash.html>
I invite all members of the previous discussion, as well as anyone
interested in Array vs Hash mechanics in JavaScript to read this
article and to express your opinion (if any).
Comment: "You can use a notation like arrayObject[-1] top address the
last element in the array". Nope, doesn't work. It merely tries to
access the property named "-1", which doesn't exist unless you created
it.
Re. "multidimensional arrays". Javascript doesn't have mutidimensional
arrays in the sense of C, b ut only arrays of arrays. In C you wouldn't
be able to change a sub-array like:
int arr[4][4];
arr[3] = new int[4];
"The actual amount of possible indexes (dimensions) is platform
dependent, but always very big, so you should not worry about it."
It's not really platform dependent either, just limited by available
memory. Or, for a seemingly infinite-dimension array:
var x = []
x[0] = x;
You need to define what you mean by "element" of an array. You use it
in the sense "what you get when indexing with an integer less than the
array's length". That makes "new Array(10)" have ten elements, all
undefined. Other people (myself included) uses "element" to mean
an actual property of the array object, so "new Array(10)" has no
elements. This is a more usual meaning for *sparse* arrays, where
not all indices correspond to an "element".
You sortof say it in the section following this:
" Nevertheless it is important to understand the difference of (1)
undefined value received from a non-instantiated element within your
array and (2) undefined value received when addressing an element with
index bigger than length-1."
I think that's a dangerous way to make the point. There is no
difference between the "undefined" values you get, nor between the
underlying functionality that gives you that "undefined". What you
are trying to say is that:
Arrays in Javascript are an abstraction on top of normal object
properties. For property names that are (bounded) integers, it
works as if the array was a contiguous sequence of values, some
of them "undefined", indxed from 0 to one less than the arrays
"length" property's value.
Arrays are *implemented* as sparse arrays. Only the indices that have
been assigned to, take up space, and the "length" property only
guarantees to be larger than the largest index in use.
The methods operating on arrays respect the abstraction and all treat
the array as a contiguous sequence of, potentially "udefined" values.
[[ your example with "slice" ]].
Make no mistake, at the specification level, there is a difference
between being unassigned and having been assigned the value
"undefined". Example:
var arr = [1,,undefined,true];
arr[2]=undefined; // for IE's bug (2 in arr == false)
delete arr[1]; // for Firefox's bug (1 in arr == true)
alert([arr.length, 1 in arr, 2 in arr]); // 4,false,true
arr = arr.sort();
alert([arr.length, 2 in arr, 3 in arr]); // 4,true,false
I.e., unassigned indices are sorted as larger than those assigned
"undefined". (Not all implementationts are correct, e.g., Firefox
gives 4,true,true for the last one).
"On Macintosh platform an attempt to use a number for hash key leads
to an error. As a workaround, if you really need to have a number as
hash key (?), always put it into quotes."
Are you talking about Javascript objects here? It's not obvious.
Also, "Macintosh platform" is far from an exact specification of
the Javascript implementation that fails. It could be the one in
IE5.2, in Safari, in Galleon, in OmniWeb, ...
"JavaScript doesn't have a built-in constructor for hash objects. But
each object supports hash table mechanics inherited from the Object
prototype."
It's not Object.prototype that have string based properties, it's
just objects themselves. If you find a way to create an object without
inheriting Object.prototype, you can still add properties to it.
"Unfortunately interpreter doesn't resolve variables in such
declarations. Everything (quoted or not quoted) will be treated as
string literals."
Not so. It's variables in the keys that doesn't work, the values
work fine:
var x = 42;
var h = {foo: x, x:x, "y":x, "Lorem ipsum, lala": x, "":x};
There is no guarantee that implementations have efficient property
look-up. It seems like IE have linear time look-up of properties.
What is an "out of papers" language?
"Later it was called "JavaScript collection" and blessed to the
standard". You are referring to the DOM standard, before mentioning it
in the next paragraph. It is called an "HTMLCollection". It has the
interface:
interface HTMLCollection {
readonly attribute unsigned long length;
Node item(in unsigned long index);
Node namedItem(in DOMString name);
};
In the ECMAScript binding, both can be called indirectly by using the
square bracket notation (which is equivalent with the dot-notation
when the property name is a valid identifier).
<URL:
http://www.w3.org/TR/DOM-Level-2-HTML/ecma-script-binding.html>
"I strongly encourage you while working with forms and frames always
use index notation:
document.forms[0].elements[0];
window.frames[0]
That will make your code more stable and predictable."
I disagree. Using numeric indices is not stable against changes
to the page. If you insert a form before the one you refer to here,
you also need to change the index. Instead use:
document.forms['formId'].elements['elementName']
widow.frames['frameName']
It is safer. You do get collections when more than one element
have the same name, but that should not come as a surprise to you,
if you created the form. You can just traverse that collection then.
(and yes,
document.forms.formId.elements.elementName
is just as good when elementName is a valid identifier)
"then later we should address them respectively:
arrayObject[0];
hashObject{'key'};"
I fail to see why the format of a literal should define the format
of a lookup, but well, you are entitled to your opinion
Generally: The part about arrays is ok, with small nitpicks. The part
about hashes doesn't seem as coherent. It's a jubmle of independent
points, without a common goal. In other words: Find out what your
main point is, and build up to it.
/L
