<FAQENTRY> Array and hash (associative array)

Discussion in 'Javascript' started by VK, Jun 18, 2005.

  1. VK

    VK Guest

    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]
    VK, Jun 18, 2005
    #1
    1. Advertising

  2. VK wrote:
    > 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.

    <snip>
    > 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.
    Richard Cornford, Jun 18, 2005
    #2
    1. Advertising

  3. VK

    VK Guest

    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.
    VK, Jun 18, 2005
    #3
  4. In article <>, VK
    <> writes
    >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
    --
    John Harris
    John G Harris, Jun 18, 2005
    #4
  5. JRS: In article <>,
    dated Sat, 18 Jun 2005 07:58:48, seen in news:comp.lang.javascript, VK
    <> posted :

    >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.

    --
    © John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
    <URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
    <URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
    <URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
    Dr John Stockton, Jun 18, 2005
    #5
  6. VK

    Jc Guest

    Richard Cornford wrote:
    > VK wrote:
    > > 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.

    <snip>

    > > 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.
    Jc, Jun 18, 2005
    #6
  7. Dr John Stockton <> writes:

    > 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
    --
    Lasse Reichstein Nielsen -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
    Lasse Reichstein Nielsen, Jun 19, 2005
    #7
  8. VK

    VK Guest

    > 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, Jun 19, 2005
    #8
  9. VK

    VK Guest

    > 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, Jun 19, 2005
    #9
  10. VK

    VK Guest

    > 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);
    }
    VK, Jun 19, 2005
    #10
  11. VK wrote:
    >> 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.


    "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, Jun 19, 2005
    #11
  12. VK wrote:
    >> 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:


    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.
    Richard Cornford, Jun 19, 2005
    #12
  13. "VK" <> writes:

    >> 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
    --
    Lasse Reichstein Nielsen -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
    Lasse Reichstein Nielsen, Jun 19, 2005
    #13
  14. VK

    VK Guest

    > 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.
    VK, Jun 19, 2005
    #14
  15. On 19/06/2005 13:29, VK wrote:

    >> 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

    --
    Michael Winter
    Replace ".invalid" with ".uk" to reply by e-mail.
    Michael Winter, Jun 19, 2005
    #15
  16. VK wrote:
    >> 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.


    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.
    Richard Cornford, Jun 19, 2005
    #16
  17. VK

    VK Guest

    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 :)
    VK, Jun 19, 2005
    #17
  18. "VK" <> writes:

    > 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
    --
    Lasse Reichstein Nielsen -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
    Lasse Reichstein Nielsen, Jun 19, 2005
    #18
  19. VK wrote:
    > 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.
    Richard Cornford, Jun 19, 2005
    #19
  20. VK

    VK Guest

    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.
    VK, Jun 19, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. desktop
    Replies:
    5
    Views:
    383
    James Kanze
    Jun 26, 2007
  2. VK
    Replies:
    36
    Views:
    642
    Martin Honnen
    Aug 3, 2005
  3. VK
    Replies:
    19
    Views:
    152
    Dr J R Stockton
    Jan 30, 2007
  4. VK
    Replies:
    3
    Views:
    178
    Dr J R Stockton
    Mar 15, 2007
  5. VK
    Replies:
    3
    Views:
    80
    David Mark
    Feb 11, 2008
Loading...

Share This Page