Array and Hash in JavaScript : materials for FAQ : v2

[VK]

A while ago I proposed to update info in the group FAQ section, but I
dropped the discussion using the approach "No matter what color the cat
is as long as it still hounts the mice". Over the last month I had
enough of extra proof that the cat doesn't hount mice anymore in more
and more situations. And the surrent sicretisme among array and hash is
the base for it.

I summarized all points in this article:
<http://www.geocities.c om/schools_ring/ArrayAndHash.ht ml>

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

As each point in the article is illustrated by a concrete code sample,
I expect do not see any abstract considerations/injurations. But of
course factual mistakes illustrated by contre-samples should be edited
immediately.

[John G Harris]

In article <11************ **********@g47g 2000cwa.googleg roups.com>, VK
<sc**********@y ahoo.com> writes

<snip>

array consists of "data holders", and length indicates the amount of
data holders in each dimensions.

<snip>

The length indicates whatever the Language Standard says it indicates,
no more, no less.

If you don't like what it indicates then use another language.

John
--
John Harris

[John G Harris]

In article <11************ *********@f14g2 000cwb.googlegr oups.com>, VK
<sc**********@y ahoo.com> writes

<snip>

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

<snip>

Please stop misusing the word 'Hash'. A Hash Table, aka Hash Map, is
just one way of implementing what's needed for objects.

There are other ways of implementing what's needed. Some of them are
more appropriate when most objects have a small number of properties.
E.g. A linked list, a tree.

John
--
John Harris

[VK]

> The length indicates whatever the Language Standard says it indicates,

no more, no less.

Exactly. And arrayObject.len gth indicates the amount of registered
elements (data holders) in the array. And if you don't like it, you may
jump on GBasic, Focal or any other place away from here.

[VK]

John G Harris wrote:

Please stop misusing the word 'Hash'. A Hash Table, aka Hash Map, is
just one way of implementing what's needed for objects.

There are other ways of implementing what's needed. Some of them are
more appropriate when most objects have a small number of properties.
E.g. A linked list, a tree.

John
--
John Harris

We're not talking about possible programming entitities we could
invent/introduce for programming. Its name is Legion.
We're talking about existing separate programming entities in
JavaScript. Besides all others these are: Array, Associative array
(Hash) and HTMLCollection. Despite these are very different entities
with very different method/property sets, on the basic level there is a
huge cocktail of all three of them in the minds.

[VK]

Thomas 'PointedEars' Lahn wrote:

Lasse Reichstein Nielsen wrote:

"VK" <sc**********@y ahoo.com> writes:

If we move on on say VBasic.Net, we have the standard triad Nothing /
Empty / Null.

I'm not sure what makes it so standard, since I have never heard
about it before (but then again, I never did VB).

Be proud of it. VB is rather a disease than a programming language
which is why so many kiddies and so less professionals use it.

Your pointed ears again with another chunk of scum!

I don't like VB neither (looks too babish in all aspects). But VBA is
based on it, and you get good paid for good VBA modules.

But I guess you're one of these "conceptual " people who prefer to sit
with no money but keep the concept in its purity?

[Thomas 'PointedEars' Lahn]

VK wrote:

I don't like VB neither (looks too babish in all aspects). But VBA is
based on it, and you get good paid for good VBA modules.
VBA is just as bad, if not worse. Unfortunately it is the only means
(AFAIK) to script MS Office apps.
But I guess you're one of these "conceptual " people who prefer to sit
with no money but keep the concept in its purity?

I prefer not to take jobs when it has to be a programming language that
is a pain in the ass, yes.
PointedEars

[John G Harris]

In article <11************ **********@g43g 2000cwa.googleg roups.com>, VK
<sc**********@y ahoo.com> writes

John G Harris wrote:

Please stop misusing the word 'Hash'. A Hash Table, aka Hash Map, is
just one way of implementing what's needed for objects.

There are other ways of implementing what's needed. Some of them are
more appropriate when most objects have a small number of properties.
E.g. A linked list, a tree.

John
--
John Harris

We're not talking about possible programming entitities we could
invent/introduce for programming. Its name is Legion.
We're talking about existing separate programming entities in
JavaScript. Besides all others these are: Array, Associative array
(Hash) and HTMLCollection. Despite these are very different entities
with very different method/property sets, on the basic level there is a
huge cocktail of all three of them in the minds.

You are talking about Hash Tables with their buckets (aka "hash memory
baskets") and their hashing algorithms.

You are saying that every object grabs kilobytes in case there are going
to be a lot of properties. And you are saying that some choices of
property names will be worst case : wasting most buckets and with lousy
performance. ECMA 262 does NOT require this.

John
--
John Harris

[John G Harris]

In article <11************ **********@g47g 2000cwa.googleg roups.com>, VK
<sc**********@y ahoo.com> writes

<John said>

The length indicates whatever the Language Standard says it indicates,
no more, no less.

Exactly. And arrayObject.len gth indicates the amount of registered
elements (data holders) in the array. And if you don't like it, you may
jump on GBasic, Focal or any other place away from here.

The Language Standard says
"The length property of this Array object is always numerically greater
than the name of every property whose name is an array index."
which is not what you've just said.

John
--
John Harris

[VK]

John G Harris wrote:

You are saying that every object grabs kilobytes in case there are going
to be a lot of properties. And you are saying that some choices of
property names will be worst case : wasting most buckets and with lousy
performance. ECMA 262 does NOT require this.

John
--
John Harris

I'm cannot say it until I conduct the tests. Maybe the hash mechanics
is implemented in JavaScript objects, maybe not.
On the first loot at the native objects at least (the order of
methods/properties as they listed through the for-in loop) presumably
hash mechanics is implemented or at least mimiced.

HTMLCollection for sure has nothing to do with baskets - it's build by
the order the elements appear on the page.

And in any case you as programmer do not have to worry about some
special property naming for a "better basket packaging". As you don't
need to allocate memory for your var's (talking JavaScript only).

[John G Harris]

In article <11************ **********@f14g 2000cwb.googleg roups.com>, VK
<sc**********@y ahoo.com> writes

John G Harris wrote:

You are saying that every object grabs kilobytes in case there are going
to be a lot of properties. And you are saying that some choices of
property names will be worst case : wasting most buckets and with lousy
performance. ECMA 262 does NOT require this.

John
--
John Harris
I'm cannot say it until I conduct the tests. Maybe the hash mechanics
is implemented in JavaScript objects, maybe not.

If 'maybe not' then you mustn't say objects use hash tables.

On the first loot at the native objects at least (the order of
methods/properties as they listed through the for-in loop) presumably
hash mechanics is implemented or at least mimiced.
Properties might be listed in the order they were put into the object,
and you can't say what that order is for a native object.

Hash tables mimic the general requirements of associative arrays, not
the other way around.

HTMLCollecti on for sure has nothing to do with baskets - it's build by
the order the elements appear on the page.
It is still built from objects, using object properties.

And in any case you as programmer do not have to worry about some
special property naming for a "better basket packaging". As you don't
need to allocate memory for your var's (talking JavaScript only).

With hash tables you always have to worry. They can turn round and bite
you if you don't know the hashing algorithm, and if you do know it you
can still be very unlucky.

The second sentence doesn't make sense. Do you really know what a hash
table is?

John
--
John Harris