Order of Key-Value pair ("associative arrays")

[John G Harris]

Re: Order of Key-Value pair ("associat ive arrays")

In article <8yf9viwq.fsf@h otpop.com>, Lasse Reichstein Nielsen
<lrn@hotpop.com > writes[color=blue]
>John G Harris <john@nospam.de mon.co.uk> writes:
>[color=green]
>> It's the other way round. Every ECMAScript object is an associative
>> array.[/color]
>
>... where "associativ e array" is just mumbo-jumbo for a mapping from
>something to something. I believe the name comes from Perl, although
>they could have taken it from somewhere else. It is really a misnomer,
>as it has nothing to do with "real" arrays.[/color]

Back in the 1960s a lot of people got very excited about associative
memory. It was, at last, possible to build one with less than a roomful
of electronics. As it happens its most common use these days is in
memory caches. These are buried inside processor chips and so are not
very visible to users.

An ordinary array is built from ordinary memory. You put in a relative
address and a value comes back very, very quickly.

An associative array is built from associative memory. You put in a key
and a value comes back also very, very quickly ... if you can afford to
use a million or so transistors. It's a lot slower if you have to use
software to do it.

Altogether, "associativ e array" is a perfectly respectable technical
term that goes back a long way. It's wrong to complain if someone uses
it.
[color=blue]
>In, e.g., Java, I would never say "associativ e array". I'd just say
>"Map".[/color]

In Java, what have Map and Dictionary got in common? They are both
associative arrays. It's not very clear if you have to say that one is a
Map and so is the other. And in C++ you can use array syntax, a[b], to
get at the values.

John
--
John Harris

[Thomas 'PointedEars' Lahn]

Re: Order of Key-Value pair (&quot;associat ive arrays&quot;)

Lasse Reichstein Nielsen wrote:
[color=blue]
> John G Harris <john@nospam.de mon.co.uk> writes:[color=green]
>> It's the other way round. Every ECMAScript object is an associative
>> array.[/color]
>
> ... where "associativ e array" is just mumbo-jumbo for a mapping from
> something to something. I believe the name comes from Perl, although
> they could have taken it from somewhere else. It is really a misnomer,
> as it has nothing to do with "real" arrays.
>
> In, e.g., Java, I would never say "associativ e array". I'd just say
> "Map".[/color]

Full ACK. To me, an "array" in computer science and thus programming is
an *ordered* data structure (AIUI an "array" outside of computer science
has the property of order as well), composed of *elements*. That means,
one can access element #x or append elements at the end of to the array
directly, without iteration.

With a simple non-Array[1] ECMAScript object there are no such means
available. You cannot access property #x unless you indexed it before
and you cannot obtain the number of properties until you iterated the
object using a for-in-loop. And even then you cannot tell for sure that
these are all properties of the object (which would be then elements of
the "associativ e array" if you like call them so) because some may have
the NonEnum flag set and thus do not occur during iteration but yet are
present. And single properties can be read-only. I don't know of any
implementation that calls itself an "array" and that allows that kind
of data hiding and level of data integrity protection regarding the
elements of that "array".

With an Array[1] ECMAScript object there is a distinction between array
elements and object properties (as already shown). Array elements can be
refered to as object properties with a(n) (numeric) index, but not all
properties of an Array (object) are elements of the array (data structure)
it encapsules.

In contrast, in PHP for example, there are what I would consider associative
arrays or maps. If you do

$a = array();
$a['foo'] = 'bar';

or

$a = array(
'foo' => 'bar'
);

You can access $a['foo'] with $a[0] as well because it is the first
element appended to the array. (Look how the "=>" operator tells
of the mapping that is done.)

Achieving that in ECMAScript and implementations requires another data
structure similar to Array objects, which I refer to as a "collection ",
as specified for example with the HTMLCollection interface of the W3C
DOM.


PointedEars
___________
[1] Note the character case!

[Grant Wagner]

Re: Order of Key-Value pair (&quot;associat ive arrays&quot;)

John G Harris wrote:
[color=blue]
> In article <40B94760.10403 01@PointedEars. de>, Thomas 'PointedEars' Lahn
> <PointedEars@nu rfuerspam.de> writes[color=green]
> >Abdullah Kauchali wrote:
> >[color=darkred]
> >> Can one rely on the order of keys inserted into an associative Javascript
> >> array? For example:[/color]
> >
> >JavaScript and other ECMAScript implementations have no built-in
> >concept of associative arrays.[/color]
> <snip>
>
> It's the other way round. Every ECMAScript object is an associative
> array.[/color]

No, every ECMAScript object is an object that can have properties which can be
accessed using dot notation (theObject.theP roperty), or "array" notation
(theObject[theProperty]).
[color=blue]
> Even Array objects are associative arrays. It's a syntax fudge that
> makes Array objects look, almost, like the arrays in other languages
> with their numeric indexes.[/color]

No, an Array object is a special object that represents an array. Array objects
are "magical" (as is the Location object for a similar reason) because setting
the value of an array index updates properties within the object, something that
is not possible with other objects in an ECMA-262 compliant way. The closest you
could get would be to use watch()/unwatch() in Netscape to monitor the updating
of a property and act on it to update another property:

var myArray = new Object();
myArray.blahHan dler = function() {
alert('blah changed');
}
myArray.watch(' blah', myArray.blahHan dler);
myArray.blah = 1;

But even this doesn't approximate the behavior of the Array object, where the
updating of an arbitrary "associativ e array" key that is an integer updates the
length property of the object. Of course, one could argue that length isn't
updated immediately, but instead returns a "count" of the number of properties
attached to the Array object, but in that case, Array would still be "magical",
with .length acting as a method call without "()" (and it seems pretty obvious
from speed tests that .length doesn't actually execute any code to "count" the
number of entries but is, at it appears to be, a simple property containing a
value).

By the way, Location is "magical" because it behaves in a way that is impossible
if it were a normal object When you do window.location .href =
'http://www.yahoo.com'; and window.location = 'http://www.yahoo.com'; and they
result in the same action, it would be like expecting:

var location = new Object();
location.href = 'http://www.yahoo.com';

and

var location = new Object();
location = 'http://www.yahoo.com';

to have the same outcome.

--
| Grant Wagner <gwagner@agrico reunited.com>

* Client-side Javascript and Netscape 4 DOM Reference available at:
*

http://devedge.netscape.com/library/manuals/2000/javascript/1.3/reference/frames.html

* Internet Explorer DOM Reference available at:
*

http://msdn.microsoft.com/workshop/author/dhtml/reference/dhtml_reference_entry.asp

* Netscape 6/7 DOM Reference available at:
* http://www.mozilla.org/docs/dom/domref/
* Tips for upgrading JavaScript for Netscape 7 / Mozilla
* http://www.mozilla.org/docs/web-deve...upgrade_2.html

[Lasse Reichstein Nielsen]

Re: Order of Key-Value pair (&quot;associat ive arrays&quot;)

Grant Wagner <gwagner@agrico reunited.com> writes:
[color=blue]
> By the way, Location is "magical" because it behaves in a way that is impossible
> if it were a normal object When you do window.location .href =
> 'http://www.yahoo.com'; and window.location = 'http://www.yahoo.com'; and they
> result in the same action, it would be like expecting:[/color]

<nitpick>
Technically, it would be both the location object and the window
object that are magical.

In both cases, assigning to a property will have a different effect
than the expected one. For the location object, assigning to the
"href" property changes the page's location, which is quite a side
effect. For the window object, assigning to the "location" property
doesn't change its value, but changes "location.h ref" instead.

</nitpick>
/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.'

[rh]

Re: Order of Key-Value pair (&quot;associat ive arrays&quot;)

Grant Wagner wrote:[color=blue]
> John G Harris wrote:
>[/color]
<snip>[color=blue][color=green]
> > It's the other way round. Every ECMAScript object is an associative
> > array.[/color]
>
> No, every ECMAScript object is an object that can have properties which can be
> accessed using dot notation (theObject.theP roperty), or "array" notation
> (theObject[theProperty]).
>[/color]

The original statement is correct. The accessor syntax, while being
important, doesn't change the fundamental (logical) nature of the
object.
[color=blue][color=green]
> > Even Array objects are associative arrays. It's a syntax fudge that
> > makes Array objects look, almost, like the arrays in other languages
> > with their numeric indexes.[/color]
>
> No, an Array object is a special object that represents an array. Array objects
> are "magical" (as is the Location object for a similar reason) because setting
> the value of an array index updates properties within the object, something that
> is not possible with other objects in an ECMA-262 compliant way. The closest you
> could get would be to use watch()/unwatch() in Netscape to monitor the updating
> of a property and act on it to update another property:
>[/color]

Again, the original statement is correct.

Array objects have a special "length" property, and some special
methods (notably sort) that provide further array manipulation
functionality within the language that distinquish them from standard
objects. Nonetheless, there is no access to the underlying structure
except through the standard object accessors. Therefore, regardless of
any particular implementation, Array objects remain entirely
associative in nature within the language.

<snip>
[color=blue]
> By the way, Location is "magical" because it behaves in a way that is impossible
> if it were a normal object.[/color]

Yes, but host objects are outside ECMA-262, and there's all kinds of
"magic" once you step out there. :)

../rh

[Thomas 'PointedEars' Lahn]

Re: Order of Key-Value pair (&quot;associat ive arrays&quot;)

rh wrote:
[color=blue]
> Grant Wagner wrote:[color=green]
>> John G Harris wrote:[color=darkred]
>> > It's the other way round. Every ECMAScript object is an associative
>> > array.[/color]
>>
>> No, every ECMAScript object is an object that can have properties which can be
>> accessed using dot notation (theObject.theP roperty), or "array" notation
>> (theObject[theProperty]).
>>[/color]
>
> The original statement is correct. The accessor syntax, while being
> important, doesn't change the fundamental (logical) nature of the
> object.[/color]

The fundamental (logical) nature of any object is not to be an "associativ e
array" (whatever that might be) but to be an object having properties and
methods, encapsulating data. Only because ECMAScript is a loosely typed
language where properties can be added and removed during runtime and those
of type "function" are considered methods of the object, does not make an
object per se an array. You cannot inherit from arrays, for example.


PointedEars

[Lee]

Re: Order of Key-Value pair (&quot;associat ive arrays&quot;)

Thomas 'PointedEars' Lahn said:[color=blue]
>
>Lasse Reichstein Nielsen wrote:
>[color=green]
>> John G Harris <john@nospam.de mon.co.uk> writes:[color=darkred]
>>> It's the other way round. Every ECMAScript object is an associative
>>> array.[/color]
>>
>> ... where "associativ e array" is just mumbo-jumbo for a mapping from
>> something to something. I believe the name comes from Perl, although
>> they could have taken it from somewhere else. It is really a misnomer,
>> as it has nothing to do with "real" arrays.
>>
>> In, e.g., Java, I would never say "associativ e array". I'd just say
>> "Map".[/color]
>
>Full ACK. To me, an "array" in computer science and thus programming is
>an *ordered* data structure (AIUI an "array" outside of computer science
>has the property of order as well), composed of *elements*. That means,
>one can access element #x or append elements at the end of to the array
>directly, without iteration.[/color]

Where do you get the requirement of being able to find the end
without iteration? Ever program in C?

[color=blue]
>With a simple non-Array[1] ECMAScript object there are no such means
>available. You cannot access property #x unless you indexed it before
>and you cannot obtain the number of properties until you iterated the
>object using a for-in-loop. And even then you cannot tell for sure that
>these are all properties of the object (which would be then elements of
>the "associativ e array" if you like call them so) because some may have
>the NonEnum flag set and thus do not occur during iteration but yet are
>present. And single properties can be read-only. I don't know of any
>implementati on that calls itself an "array" and that allows that kind
>of data hiding and level of data integrity protection regarding the
>elements of that "array".[/color]

The fact that an associative array doesn't fit the
definition of an array shouldn't be so disturbing.

Your argument reminds me of somebody complaining that
the term "magnetic field" is improper because a "field"
is something that you can plant corn in.

There is certainly nothing that precludes an associative
array from also implementing private fields, etc.

[rh]

Re: Order of Key-Value pair (&quot;associat ive arrays&quot;)

Thomas 'PointedEars' Lahn <PointedEars@nu rfuerspam.de> wrote in message news:<40C1B4E1. 6040502@Pointed Ears.de>...[color=blue]
> rh wrote:
>[color=green]
> > Grant Wagner wrote:[color=darkred]
> >> John G Harris wrote:
> >> > It's the other way round. Every ECMAScript object is an associative
> >> > array.
> >>
> >> No, every ECMAScript object is an object that can have properties which can be
> >> accessed using dot notation (theObject.theP roperty), or "array" notation
> >> (theObject[theProperty]).
> >>[/color]
> >
> > The original statement is correct. The accessor syntax, while being
> > important, doesn't change the fundamental (logical) nature of the
> > object.[/color]
>
> The fundamental (logical) nature of any object is not to be an "associativ e
> array" (whatever that might be) but to be an object having properties and
> methods, encapsulating data.[/color]

As described earlier in this thread, an associative array is a
well-defined mapping of keys to values. In computing, they are an
abstract data type, which means they are defined by the operations
they support, rather than in terms of their underlying implementation.
They can also be considered to be a form of generalization of an array
which supports only integers as indexes.
[color=blue]
> Only because ECMAScript is a loosely typed
> language where properties can be added and removed during runtime and those
> of type "function" are considered methods of the object, does not make an
> object per se an array.[/color]

No, but it does mean that an objects ECMAScript are conceptually based
on associative arrays. The keys are "property names" and the values
are scalars or other objects, such as functions. And while some
language implementations may have confined associative array values to
being scalars, and/or all values must be of the same type, there's
nothing inherent in the concept of associative arrays that requires
such constraints to prevail.

Since dynamic addition and removal of keys/values is fundamental to
associative array operation, and you recognize the fact that
ECMAScript supports such for objects, you're simply lending
confirmation to the contention that ECMAScript objects are in fact,
fundamentally, associative arrays.

../rh

[rh]

Re: Order of Key-Value pair (&quot;associat ive arrays&quot;)

Lee wrote:
[color=blue]
> Your argument reminds me of somebody complaining that
> the term "magnetic field" is improper because a "field"
> is something that you can plant corn in.
>[/color]

Would that perhaps be the same person that claimed to have Grade 12
equivalency because he had gone through Grade 6 twice? :-).

../rh

[Thomas 'PointedEars' Lahn]

Re: Order of Key-Value pair (&quot;associat ive arrays&quot;)

rh wrote:
[color=blue]
> Thomas 'PointedEars' Lahn [...] wrote [...]...[color=green]
>> rh wrote:
>> Only because ECMAScript is a loosely typed
>> language where properties can be added and removed during runtime and those
>> of type "function" are considered methods of the object, does not make an
>> object per se an array.[/color]
>
> No, but it does mean that an objects ECMAScript are conceptually based
> on associative arrays.[/color]

Obviously you have not the slightest idea of OOP
or of ECMAScript and its implementations as OOLs.


PointedEars

[rh]

Re: Order of Key-Value pair (&quot;associat ive arrays&quot;)

Thomas 'PointedEars' Lahn wrote:[color=blue]
> rh wrote:
>[color=green]
> > Thomas 'PointedEars' Lahn [...] wrote [...]...[color=darkred]
> >> rh wrote:
> >> Only because ECMAScript is a loosely typed
> >> language where properties can be added and removed during runtime and those
> >> of type "function" are considered methods of the object, does not make an
> >> object per se an array.[/color]
> >
> > No, but it does mean that an objects ECMAScript are conceptually based
> > on associative arrays.[/color]
>
> Obviously you have not the slightest idea of OOP
> or of ECMAScript and its implementations as OOLs.
>[/color]

True or otherwise, whatever, that statement would constitute yet
another red herring pulled from your red herring fishnet[1] and ever
so deftly laid across the trail.

../rh

[1] Red herring fishnet: a capturing device used by those with unusual
perspectives, most often consisting of a bunch of holes tied together
with string. When constructed as a rectangle, the device can actually
appear to be an array.

[Marek Mänd]

Re: Order of Key-Value pair (&quot;associat ive arrays&quot;)

Douglas Crockford wrote:
[color=blue][color=green]
>> Can one rely on the order of keys inserted into an associative Javascript
>> array? For example:
>>
>> var o = new Object();
>>
>> o["first"] = "Adam";
>> o["second"] = "Eve";
>> o["third"] = "Cane";
>> o["fourth"] = "Abel";[/color]
> No. The ECMAScript specification allows the contents of an object to be
> unordered. Most implementations do order the contents, but you should
> not rely on that.[/color]

Yes, whilst IE seems to preserve ordering, Opera7 definately doesnt.

--
marekmand

[Grant Wagner]

Re: Order of Key-Value pair (&quot;associat ive arrays&quot;)

Marek Mänd wrote:
[color=blue]
> Douglas Crockford wrote:
>[color=green][color=darkred]
> >> Can one rely on the order of keys inserted into an associative Javascript
> >> array? For example:
> >>
> >> var o = new Object();
> >>
> >> o["first"] = "Adam";
> >> o["second"] = "Eve";
> >> o["third"] = "Cane";
> >> o["fourth"] = "Abel";[/color]
> > No. The ECMAScript specification allows the contents of an object to be
> > unordered. Most implementations do order the contents, but you should
> > not rely on that.[/color]
>
> Yes, whilst IE seems to preserve ordering, Opera7 definately doesnt.[/color]

One way to preserve order in these cases is to create an array that keeps track
of the keys in the order you want. It also lets you initialize the object's
properties pretty easily.

var o = {};
var keys = [ "first", "second", "third", "fourth" ];
var values = [ "Adam", "Eve", "Cane", "Abel" ];
var len = keys.length;
while (len-- > ) {
o[keys[len]] = values[len];
}

for (var i = 0; i < keys.length; i++) {
document.write( o[keys[i]] + "<br>");
}

--
Grant Wagner <gwagner@agrico reunited.com>
comp.lang.javas cript FAQ - http://jibbering.com/faq