<FAQENTRY> Array and hash (associative array)

[Richard Cornford]

Re: &lt;FAQENTRY&gt ; Array and hash (associative array)

VK wrote:[color=blue][color=green]
>> What exactly is an "end-user" of javascript?[/color]
>
> 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.[/color]

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.
[color=blue]
> So it's equal for him/her if that "undefined" is just
> created by internal sub or indeed was kept somewhere
> in the memory.[/color]

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]

Re: &lt;FAQENTRY&gt ; Array and hash (associative array)

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.l ength; 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)arrayOb ject

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

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(107374182 2); // for Windows platforms

and

var arrayObject = new Array(10);
really means:
// var arrayObject = new Array(10); // silently ignored
var arrayObject = new Array(107374182 2); // 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]

Re: &lt;FAQENTRY&gt ; Array and hash (associative array)

"VK" <schools_ring@y ahoo.com> writes:
[color=blue]
> 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).[/color]

Difinition of what? Please include at least some context of what your
are replying to.
[color=blue]
> So *programmically * my proof is here:
>
> var arrayObject = new Array(10);
> arrayObject[100] = 1;
> for (i=0; i<arrayObject.l ength; i++) {
> // 100 cicles, 100 values
> }[/color]


Proof of what. How does this differ from:

var arrayObject = new Array(10); //arrayObject.len gth == 10
for (i=0; i < 101; i++) {
// ... ?
}
[color=blue]
> 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)arrayOb ject[/color]

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

[color=blue]
> 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(107374182 2); // for Windows platforms[/color]

No. The latter has arrayObject.len gth == 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
)
[color=blue]
> var arrayObject = new Array(10);
> really means:
> // var arrayObject = new Array(10); // silently ignored
> var arrayObject = new Array(107374182 2); // for Windows platforms[/color]

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.

[color=blue]
> 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.[/color]

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 - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[Richard Cornford]

Re: &lt;FAQENTRY&gt ; Array and hash (associative array)

VK wrote:[color=blue]
> 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)[/color]

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.
[color=blue]
> So *programmically * my proof is here:
>
> var arrayObject = new Array(10);
> arrayObject[100] = 1;
> for (i=0; i<arrayObject.l ength; i++) {
> // 100 cicles, 100 values[/color]

101 cicles, 101 values. Give up the drink.
[color=blue]
> }[/color]

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.
[color=blue]
> And *programmically * the properties collection
> check below doesn't proof anything, because we're
> downcasting Array back to Object[/color]

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.
[color=blue]
> and studying it from that level.
> So we actually do (in Java notation):
> (Object)arrayOb ject[/color]

You cannot cast objects in javascript because they are
all_of_exactly_ the_same_type.
[color=blue]
> for (objectProperty in arrayObject) {
> // 1 cicle, 1 value for (Object)arrayOb ject
> }
>
> JavaScript frees programmer from the "manual" memory
> allocation, so *any* array can have as many members
> as it allowed by the language specs.[/color]

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.
[color=blue]
> 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(107374182 2); // for Windows platforms
>
> and
>
> var arrayObject = new Array(10);
> really means:
> // var arrayObject = new Array(10); // silently ignored
> var arrayObject = new Array(107374182 2); // for Windows platforms[/color]

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?
[color=blue]
> 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.[/color]

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.
[color=blue]
> P.S. So much for hash :-)[/color]

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

Re: &lt;FAQENTRY&gt ; Array and hash (associative array)

OK
JavaScript array is not really an array.
arrayObject.len gth 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.len gth
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.len gth
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.

[Michael Winter]

Re: &lt;FAQENTRY&gt ; Array and hash (associative array)

On 19/06/2005 20:40, VK wrote:
[color=blue]
> OK
> JavaScript array is not really an array.[/color]

That probably depends on the definition that you want to use. The
definition that I'm accustomed to is a homogeneous collection of
elements located sequentially in memory. However, more generic
definitions are just as acceptable.

What arrays in ECMAScript certainly are, are Object objects with
specialised behaviour. The same can be said for any native object.
[color=blue]
> arrayObject.len gth keeps the highest index you managed to use so far.[/color]

The highest plus one.
[color=blue]
> It has *no* connection with the actual array's length, it's just called
> so for further convenience.[/color]

I disagree. The array:

[, 1]

has two elements, and a length of two. Just because the first element is
undefined doesn't make the size any smaller. If you think it should,
then you are probably using the wrong data type.

[snip]
[color=blue]
> 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[/color]

OK, how many times does this need to be said: an array is not an
associative array, and an object is not an associative array. That might
be how they are implemented, and that's the sort of behaviour they
appear to possess, but that doesn't change the reality of the situation.
[color=blue]
> if you do arrayObject[SomeNumber] = someValue, it counts it in
> arrayObject.len gth[/color]

If SomeNumber is a 32-bit unsigned integer, yes.
[color=blue]
> It also lets you to use standard array methods on this member. (1st
> category)[/color]

The Array prototype methods generally operate in the range of named
properties [0, length), so that much is obvious. Some work outside that
range, namely when extending the number of elements.
[color=blue]
> if you do arrayObject[SomeString] = someValue, the engine doesn't it in
> arrayObject.len gth[/color]

If SomeString represents an array index, then that assignment certainly
does affect the length. If SomeString is not an array index, then of
course it won't affect the length.
[color=blue]
> and you cannot use standard array methods on this member. (2nd
> category)[/color]

For the previously cited reason.
[color=blue]
> Until JavaScript/JScript engine producer will rectify this obvious bug,[/color]

It is not a bug. It is clearly defined behaviour.
[color=blue]
> you need to be very attentive while putting new members in your
> arrayObject. [...][/color]

One merely needs to understand the language. You clearly don't. I
suggest you get yourself a copy of ECMA-262 and read items 15.4 and
15.4.5.1, and compare the latter to 8.6.2.2.

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

[Lasse Reichstein Nielsen]

Re: &lt;FAQENTRY&gt ; Array and hash (associative array)

Michael Winter <m.winter@bluey onder.co.invali d> writes:
[color=blue]
> I disagree. The array:
>
> [, 1]
>
> has two elements, and a length of two.[/color]

I can see why Mr. VK gets confuzed, because I would say that this
array has one element and a length of two. It matters (to me) that
the array doesn't have a property called "0".

But then again, as Mr. VK also said, if I understood the Java
comparison correctly, arrays in Javascript is an abstraction on top of
an object. If you keep within the abstraction, you can treat the array
as having two elements. If you break the abstraction and uses the
array as a general object, then you need to know the implementation.

Safer languages protects their abstractions, Javascript is not one :)
[color=blue]
> OK, how many times does this need to be said: an array is not an
> associative array, and an object is not an associative array. That
> might be how they are implemented, and that's the sort of behaviour
> they appear to possess, but that doesn't change the reality of the
> situation.[/color]

<devil's advocate>
What property of an associative array does an object fail to
match?
</devil's advocate>
[color=blue][color=green]
>> Until JavaScript/JScript engine producer will rectify this obvious bug,[/color]
>
> It is not a bug. It is clearly defined behaviour.[/color]

Hear, hear.
I can't even see what the bug should be, except the failure to protect
the abstraction that is an array from its implementation.

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[Dr John Stockton]

Re: &lt;FAQENTRY&gt ; Array and hash (associative array)

JRS: In article <ll565nwe.fsf@h otpop.com>, dated Sun, 19 Jun 2005
18:09:37, seen in news:comp.lang. javascript, Lasse Reichstein Nielsen
<lrn@hotpop.com > posted :[color=blue]
>
>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[/color]
^ integer ?[color=blue]
>necessary.[/color]


The prime point is the one I made before; that the length property does
not in the general case reflect the total number of elements, but is
associated with the number of non-negative-integer-index elements.

It is in fact associated with the way in which arrays work in Algol,
Pascal, and I presume C; and arrays in javascript are often used in that
manner, with integer indexing.

Once that is understood, it will sometimes be necessary to go into the
matter further.

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

[Richard Cornford]

Re: &lt;FAQENTRY&gt ; Array and hash (associative array)

Lasse Reichstein Nielsen wrote:
<snip>[color=blue]
> Safer languages protects their abstractions, Javascript
> is not one :)[/color]

So let's not pretend it is safe, because it will turn and bite those who
assume it is.

<snip>[color=blue]
> <devil's advocate>
> What property of an associative array does an object
> fail to match?
> </devil's advocate>[/color]
<snip>

The common expectation of an "associativ e array" seems to be that the
number of key/value pairs assigned will be reflected in a - length -
property. Hence the disappointment when javascript does no such thing.

Richard.

[Michael Winter]

Re: &lt;FAQENTRY&gt ; Array and hash (associative array)

On 19/06/2005 22:18, Dr John Stockton wrote:
[color=blue]
> JRS: In article <ll565nwe.fsf@h otpop.com>, dated Sun, 19 Jun 2005
> 18:09:37, seen in news:comp.lang. javascript, Lasse Reichstein Nielsen
> <lrn@hotpop.com > posted :
>[color=green]
>> [...] the length property only guarantees to be at least one larger
>> than the highest array index in use [...][/color]
>
> ^ integer ?[/color]

Array indicies are a subset of object property names, and are only
defined in terms of 32-bit unsigned integers, so it would seem redundant.

[snip]

Could I ask a small favour of you, John? Can you check if IE4 supports
String.prototyp e.charCodeAt? Microsoft's documentation says it doesn't,
but my copy does. Though it is running on XP, it has a separate
jscript.dll library and should be independent from the system libraries.
It is with regard to other methods like Array.prototype .push.

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

[Michael Winter]

Re: &lt;FAQENTRY&gt ; Array and hash (associative array)

On 19/06/2005 23:18, Lasse Reichstein Nielsen wrote:
[color=blue]
> Michael Winter <m.winter@bluey onder.co.invali d> writes:
>[color=green]
>> I disagree. The array:
>>
>> [, 1]
>>
>> has two elements, and a length of two.[/color]
>
> [...] I would say that this array has one element and a length of two.[/color]

Whilst I still disagree, I do find it somewhat difficult to put into
words why. Perhaps it's my definition of what an array is, and why they
are normally used; a consequence of the notion of continuity, even if
the array is sparse.
[color=blue]
> It matters (to me) that the array doesn't have a property called "0".[/color]

Although I understand that the property '0' doesn't exist in that

[, 1].hasOwnProperty ('0')

returns false (interestingly, Firefox returns true), it still does have
a 0th element. It is a zero-indexed array, sparse or otherwise, so it
must have all of the elements in the range [0, length).

[snip]
[color=blue]
> <devil's advocate>
> What property of an associative array does an object fail to
> match?
> </devil's advocate>[/color]

rf answered this one a while ago. In most ways, native objects do
resemble associative arrays. They possess both put and get operations,
and indicies are not limited to just numbers. However, a native object
is never empty. This renders get operations vulnerable to cases where a
prototyped property is returned as an element, which could include
arbitrary properties introduced by user code.

Though this problem could be mitigated by user code, the associative
array is now a user object, and not a native object.

[Regarding non-array index properties not affecting length]
[color=blue]
> I can't even see what the bug should be [...][/color]

I didn't mean for the summary about to answer the question, but that's
my understanding of it.

Mike


Does the subject of this thread need to be changed so that each post
isn't flagged as a potential FAQ entry?

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

[Lasse Reichstein Nielsen]

Re: &lt;FAQENTRY&gt ; Array and hash (associative array)

Michael Winter <m.winter@bluey onder.co.invali d> writes:
[color=blue]
> It is a zero-indexed array, sparse or otherwise, so it must have all
> of the elements in the range [0, length).[/color]

So this is what it boils down to :)
Should a sparse datastructure be considered to have elements even
where they are not specified? I say no :)
[color=blue]
> However, a native object is never empty. This renders get operations
> vulnerable to cases where a prototyped property is returned as an
> element, which could include arbitrary properties introduced by user
> code.[/color]

So the property it fails to have is the ability to be empty.
That's good enough for me :)

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[VK]

Re: &lt;FAQENTRY&gt ; Array and hash (associative array)

> Does the subject of this thread need to be changed[color=blue]
> so that each post isn't flagged as a potential FAQ entry?[/color]

Maybe, but how to call this new thread? Actually it's asking for
another
<FAQENTRY> title like "Does the world really exist or it's given to me
in my sensations and experience only?"

I don't really understant this attempt to alienate JavaScript
from any other language as it was written on Mars. It has the
most of the same entities as any other programming environment.

Any programming language is an abstraction. There is only two
real things: loaded/unloaded (1/0) memory cells and processor
flags after reading these cells. From this point of view there
is only one *real* language: ASSEMBLER (w/o mnemonics of course
as a disturbtion of the purity of the picture). Anything atope
of it as a *human abstraction* to desribe the movement and
allocation of these loads in the cells. There are not any objects,
arrays, hashes, variables etc. All from above is a kind of
"public agreement" in the meaning of Plato and Aristotle.
Nothing could us stop from deciding that say "array" would be
a data conglomerate where every second item starts with "A"
(or something even more bizzare).
On the OOP level any language consists of a set of objects,
where each object inherits/overloads/adds some method/properties
to the original Object (the Father of Gods). I don't see here
any major difference from any language. You can create a Data()
object in JavaScript and use it to play your media clips. You can
create a Array() object in JavaScript and use it to hold your
hash table. (Both by extending its properties or by changing
its prototype). Do you think that JavaScript is the most flexible
here? Some languages support operator's overload. So if you are
really bored at some sleepless night, you can make "+" sign to act
as "-" and vice versa. But do we need to state that Java
(that supports it) doesn't have a "+" sign but some "math object"
acting upon how do you use it?
If we stay at this point of view then there is no any fixed object,
and we're always acting with "something that can be anything" and the
only truth may come from our runtime experience. That puts us into
the most low level of the idealisme subjectif bordering with
a pure sensualisme.

IMHO You should respect profoundly the "public agreements"
about array and hash table (map, collection).
Otherwise you're the person who doesn't pay his bills on time
(because you're benefiting of something created 'cause of a public
agreement, but you don't want to follow that agreement right after).

In the particular, if you do var arrayObject = new Array();
you have to treat arrayObject as an array exclusively.
Otherwise why the hell did you create it?

[John G Harris]

Re: &lt;FAQENTRY&gt ; Array and hash (associative array)

In article <1119280374.505 673.283390@z14g 2000cwz.googleg roups.com>, VK
<schools_ring@y ahoo.com> writes

<snip>[color=blue]
>In the particular, if you do var arrayObject = new Array();
>you have to treat arrayObject as an array exclusively.
>Otherwise why the hell did you create it?[/color]

Is that what you're trying to say : don't misuse Array objects; if you
do you'll get into trouble. I wish you'd learn to say it more clearly.

John
--
John Harris

[John G Harris]

Re: &lt;FAQENTRY&gt ; Array and hash (associative array)

In article <1119280374.505 673.283390@z14g 2000cwz.googleg roups.com>, VK
<schools_ring@y ahoo.com> writes

<snip>[color=blue]
>On the OOP level any language consists of a set of objects,
>where each object inherits/overloads/adds some method/properties
>to the original Object (the Father of Gods).[/color]
<snip>

C++ doesn't have an 'original object' type, and is all the better for
it.

John
--
John Harris