JavaScript associative arrays not ordered?

[Bart Van der Donck]

[MW] Since when has Wikipedia been an authority on the language?

[BVdD] Maybe the Netscape javascript manual then ?

[MW] That still wouldn't automatically eliminate the misuse of terminology.

Sun ?
http://java.sun.com/javascript/ajaxinaction/Ajax_in_Action_ApB.html

"The JavaScript object is essentially just an associative array,
with fields and methods keyed by name."

Microsoft ?
http://msdn.microsoft.com/msdnmag/issues/03/03/XMLFiles/

"If you need to pass in complex types [...] you can use associative
arrays in JavaScript."

myCar["make"] = "Ford"
myCar["model"] = "Mustang"
myCar["year"] = 67
This type of array is known as an associative array, because each
index element is also associated with a string value.

That's a worse description: myCar need not be an array (none of this has
/anything/ to do with arrays), and, in reference to "index element",
those strings are not indices; they are property names.

This smells like language fetishism - indices or keys are common names
to describe this kind of referencing. Doesn't matter how it's
implemented internally, it's the general working that is being
described here.

Again, I ask you to read the archives. Unless you have something new to
add, there's no point repeating this debate. I can't say that I'd look
forward to a ninth discussion of this subject.

I did read the archives, and, as you probably know, it's a
controversial subject. But if Wikipedia, Netscape, Microsoft, Sun (and
probably more) all mention associative arrays in such clear terms, I
find the "official" comp.lang.javascript point of view very
questionable.

 

[Richard Cornford]

Michael Winter wrote:

I did read the archives, and, as you probably know, it's a
controversial subject. But if Wikipedia, Netscape, Microsoft, Sun
(and probably more) all mention associative arrays in such clear
terms, I find the "official" comp.lang.javascript point of view very
questionable.

Because it makes perfect sense to follow the people who cause the
problem and disregard the people who have to deal with the
consequences. It remains the case that if you say "associative array"
you are likely introduce expectations that are not satisfied in
javascript. Inexpert authors may not know enough to appreciate that,
and so propagate their inadequacies in documents they write. The
consequences are negative and so the usage should be discouraged.

Richard.

 

[Bart Van der Donck]

Bart Van der Donck wrote:

[...] But if Wikipedia, Netscape, Microsoft, Sun
(and probably more) all mention associative arrays in such clear
terms, I find the "official" comp.lang.javascript point of view very
questionable.

Because it makes perfect sense to follow the people who cause the
problem and disregard the people who have to deal with the
consequences. It remains the case that if you say "associative array"
you are likely introduce expectations that are not satisfied in
javascript. Inexpert authors may not know enough to appreciate that,
and so propagate their inadequacies in documents they write. The
consequences are negative and so the usage should be discouraged.

I think you're missing the point. I'm not saying anything at all on how
associative arrays work/behave in javascript. A programmer must be
aware of language-specific particularities, yes, but that's only a
technical thing, not a fundamental or conceptual thing.

Those language-specific implementations don't really matter too; it is
the general principle that matters.

"Associative array" is not a "directly harmful term", as you claimed in
another post. They are an idea, a description, something that
programmers recognize, a general accepted type of variable. It's also
meant to behave that way in javascript; their syntax, lookup and
overall working are close to what you find in most other computer
languages. Even if there are things that are not possible in
javascript, doesn't mean that they are not associative arrays anymore.

Is a car without a roof not a car ? You say: "It's not a car, but a
cabrio". The second part of that statement is true, but you can't
extrapolate that fact to justify the first part. This kind of thinking
is intellectually unfair; of course it's a cabrio, but that doesn't
mean that it's not a car.

Another analogy: Is a car on electricity not a car ? Sure it is. It's
the general accepted idea of a car that matters here, not whether they
drive on fuel or gas or electricity.

 

[Richard Cornford]

Bart Van der Donck wrote:

[...] But if Wikipedia, Netscape, Microsoft, Sun
(and probably more) all mention associative arrays in such clear
terms, I find the "official" comp.lang.javascript point of view very
questionable.

Because it makes perfect sense to follow the people who cause the
problem and disregard the people who have to deal with the
consequences. It remains the case that if you say "associative array"
you are likely introduce expectations that are not satisfied in
javascript. Inexpert authors may not know enough to appreciate that,
and so propagate their inadequacies in documents they write. The
consequences are negative and so the usage should be discouraged.

I think you're missing the point. I'm not saying anything at all on
how associative arrays work/behave in javascript.

As javascript has no associative arrays they don't.

A programmer must be aware of language-specific
particularities, yes, but that's only a technical thing,
not a fundamental or conceptual thing.

You have avoided rising to the challenge of stating a detention of an
associative array that includes all the things that are associative
arrays and javascript objects. A simple definition of an associative
array might be; a thing in which values may be stored using arbitrary
key, from which that value may then be retrieved using the same key,
and with which the use of a key that has never been used to store a
value will not retrieve a value.

That definition is fairly close to the concept of an associative array,
but a javascript object does not qualify.

If you can state a viable definition of an associative array that does
not disqualify the javascript object, includes all the things that are
associative arrays and does not include things that self-evidently are
not associative arrays then there might be some reason for changing my
position. As it stands the fact that you cannot use arbitrary keys with
javascript objects (by specification) precludes their classification as
associative arrays (and suggests that anyone who wants to categorise
them as such is actually just unaware of the issues).

Those language-specific implementations don't really matter too;
it is the general principle that matters.

But the general principle is - arbitrary key == value.

"Associative array" is not a "directly harmful term", as you
claimed in another post.

Yes, a harmful term when applied to a javascript object.

They are an idea, a description, something that
programmers recognize, a general accepted type of variable.

Precisely. The term brings expectations and javascript does not satisfy
those expectations. The bugs that follow from the resulting
misconception are non-obvious, often only occurring infrequently and
unexpected, making them hard to find, if noticed at all. The result of
trying to carry an inappropriate expectation into javascript is that
the javascript authoring is worse.

It's also meant to behave that way in javascript;

Not if they don't exist in javascript.

their syntax, lookup and overall working are close to what
you find in most other computer languages.

Really? How many associative array implementations will not let you
store a value using an arbitrary key? How many will return a value that
was never stored? How many will return a value that differs from the
one stored? How many will not let you remove a key value pair that you
have previously stored.

Even if there are things that are not possible in
javascript, doesn't mean that they are not associative
arrays anymore.

How many things have to not be possible before something is not an
associative array? Is, for example, a Java Array and associative array
because you may safely use a limited set of non-arbitrary keys to store
and retrieve values of a pre-determined type? How about the Java
Vector; the same restriction to non-arbitrary keys but more flexibility
in what may be stored?

Is a car without a roof not a car ? You say: "It's not a car,
but a cabrio".

No, I would say that is a car, but I would say that the similarities
between a railway engine and a care (wheels, engine, doors, driver's
seat) are not sufficient to categorise one as a car.

Another analogy: Is a car on electricity not a car ? Sure it is. It's
the general accepted idea of a car that matters here, not whether
they drive on fuel or gas or electricity.

And if the general concept of an associative array is that arbitrary
keys may be safely used to store and retrieve values then a javascript
object does not qualify.

Richard.

 

[Matt Kruse]

And if the general concept of an associative array is that arbitrary
keys may be safely used to store and retrieve values then a javascript
object does not qualify.

How "arbitrary" must keys be in order to qualify as an associative array?
In Java since I can't use null as a key in a HashTable, is that not
arbitrary enough and therefore not an associative array?

IMO, the more accurate and easily understood explanation for javascript is
that it has associative arrays by using an Object(), but that there are some
"reserved words" which should not be used as keys. As long as you don't use
those keys, the Object() works exactly like an associative array that most
programmers on the planet would recognize.

I'd suggest that instead of the experts here constantly telling posters
"there are no associative arrays in js!" just to argue a technicality, a
more helpful response might be:

In javascript, an Object() can be used as an "associative array" to store
key/value pairs. However, since the Object in javascript has properties
(which translate into keys) by default, special care needs to be taken to
avoid naming collisions with these keys and retrieving values for keys which
were never explicitly set. So, if you want to guarantee that you won't have
problems and want to truly use arbitrary keys, this object will work:

function HashTable() { ... }

Now, wouldn't that be more helpful?

 

[Arnaud Diederen]

How "arbitrary" must keys be in order to qualify as an associative array?
In Java since I can't use null as a key in a HashTable, is that not
arbitrary enough and therefore not an associative array?

Excuse my swooping in, but Java's HashTable accepts much more "arbitrary"
keys than JavaScript's Object.

In JavaScript, you can use strings only as key. Numbers, booleans,
will translate to a string when used as a key, and that will cause no
problem, but what happens when you use an Object as key? All objects
will be translated to the same string (in SpiderMonkey, it is the
string "[object Object]", I'm not sure about other implementations).

So, you cannot use two different objects as two distinct keys, as they
will all translate to the same string.

Regards,

Arnaud.

[deletia]

 

[Richard Cornford]

How "arbitrary" must keys be in order to qualify as an associative
array?

As the keys that must be used in javascript are all strings then
sufficiently arbitrarily will be any sequence of characters.

In Java since I can't use null as a key in a HashTable, is that not
arbitrary enough and therefore not an associative array?

The difference between using anything except null and anything
including null is minimal, but is a HashTable an associative array or a
hash table?

I still think that the question of whether a javascript Object is an
associative array would be best approached by defining what is meant by
an associative array, and coming up with a definition that includes all
the things that can be agreed to be associative arrays but excludes
thing that are obviously not associative arrays (such as the Java
Vector). With that demarcation it should be easy to see that javascript
objects are not associative arrays. I would not be too concerned about
what such a definition made of Java's HashTable or HashMap objects as
they could be argued either way.

IMO, the more accurate and easily understood explanation for
javascript is that it has associative arrays by using an Object(),
but that there are some "reserved words"

It is things like that that leave me having no regard for your opinion.
"Reserved word" has an absolutely precise meaning.

which should not be used as keys. As long as you don't use
those keys,

So people will be fine if they do not use reserved words like "this",
"do", "default", "null" and "class" as object property names? That
would be total nonsense as none of those names are likely to provoke
any issues. These are the type of misunderstanding that can follow from
the imprecise use of terminology.

the Object() works exactly like an associative array that
most programmers on the planet would recognize.

If that were true why do so many programmers question the fact that the
length properties of arrays no reflect the number of properties added
to an array, or that Object objects do not have a length property by
default? These questions follow from it being suggested to them that
javascript objects can be treated as associative arrays, when they have
expectations about what an associative array is.

I'd suggest that instead of the experts here constantly telling
posters "there are no associative arrays in js!" just to argue
a technicality, a more helpful response might be:

It is not arguing a technicality; it is saying "take all those
pre-conceptions you have about associative arrays and throw them out"
as they don't apply to javascript objects.

In javascript, an Object() can be used as an "associative array" to
store key/value pairs.

Why, when you could say in javascript an Object can have named
properties added to it and removed from it at runtime, and values
assigned to those properties?

However, since the Object in javascript has properties
(which translate into keys) by default, special care needs to be taken to
avoid naming collisions with these keys and retrieving values for keys which
were never explicitly set.

So, if you want to guarantee that you won't have problems
and want to truly use arbitrary keys, this object will work:

Would you like to have another go at that sentence, as it reads
differently each time I try, and none of them makes sense?

function HashTable() { ... }

Now, wouldn't that be more helpful?

In what sense?

Richard.

 

[Richard Cornford]

In JavaScript, you can use strings only as key.

Property names are only strings in the sense of being sequences of zero
or more characters. If a property of an object is accessed as:-

var val = obj.someProperty;

- the - someProperty - is not a string (in the sense of being a
javascript string primitive or String Object), it is an Identifier.

The sense in which property names are strings is only that in a bracket
notation property accessor any expression inside the brackets is
type-converted into a string before the resulting is used to look up
the property on the object.

Numbers, booleans, will translate to a string when used as a
key, and that will cause no problem, but what happens when
you use an Object as key?

An object reference is type-converted into a string primitive. If the
object has a - toString - method then that is used (with the resulting
value being type-converted to a string if it is not one) else if the
object has a - valueOf - method that is used (with the resulting value
being type-converted to a string if it is not one (which is more
expected)), and if the object does not have either method an exception
is thrown.

All objects will be translated to the same string (in
SpiderMonkey, it is the string "[object Object]",

The - toStirng - method inherited from - Object.prototype - returns
that value. If the toString methods is overloaded all sorts of
alternative values could be returned.

I'm not sure about other implementations).

They vary.

So, you cannot use two different objects as two distinct keys, as
they will all translate to the same string.

You can effectively use object references in the brackets of bracket
notation property accessors so long as they have overloaded - toString
- methods that return suitably object-instance unique string values
that are consistent over time.

Generally that isn't done though.

Richard.

 

[Arnaud Diederen]

Numbers, booleans, will translate to a string when used as a
key, and that will cause no problem, but what happens when
you use an Object as key?

An object reference is type-converted into a string primitive. If the
object has a - toString - method then that is used (with the resulting
value being type-converted to a string if it is not one) else if the
object has a - valueOf - method that is used (with the resulting value
being type-converted to a string if it is not one (which is more
expected)), and if the object does not have either method an exception
is thrown.

All objects will be translated to the same string (in
SpiderMonkey, it is the string "[object Object]",

The - toStirng - method inherited from - Object.prototype - returns
that value. If the toString methods is overloaded all sorts of
alternative values could be returned.

I'm not sure about other implementations).

They vary.

So, you cannot use two different objects as two distinct keys, as
they will all translate to the same string.

You can effectively use object references in the brackets of bracket
notation property accessors so long as they have overloaded - toString
- methods that return suitably object-instance unique string values
that are consistent over time.

Generally that isn't done though.

Yes, that's why I kinda forgot about the fact that "[object Object]"
is simply the result of the default toString() method available on
Object.prototype.

Your whole explanation puts some pieces back into place. Thank you!

Arnaud.

Richard.

--
Arnaud DIEDEREN
Software Developer
IONIC Software
Rue de Wallonie, 18 - 4460 Grace-Hollogne - Belgium
Tel: +32.4.3640364 - Fax: +32.4.2534737
mailto:[email protected]
http://www.ionicsoft.com

 

[Matt Kruse]

I still think that the question of whether a javascript Object is an
associative array would be best approached by defining what is meant
by an associative array

And who is to make this definition? You? Because clearly the common
understanding used by Microsoft, Netscape, Sun, etc is different than yours.
And I would argue that their opinions carry more weight than yours, even if
you are technically more correct.

The difference is, you're looking to define something with absolute
certainty, whereas the term "associative array" is often casually used to
refer to "an object holding key/value pairs". Even if you disagree with the
common use of the term, you can't just choose to ignore it.

It is things like that that leave me having no regard for your
opinion. "Reserved word" has an absolutely precise meaning.

That's why I put it in quotes. Meaning, similar to but not identical to
Reserved Words. And I knew you would object.

It is not arguing a technicality; it is saying "take all those
pre-conceptions you have about associative arrays and throw them out"
as they don't apply to javascript objects.

Maybe they are your pre-conceptions. Maybe most people looking for a simple
key/value pair construct and using the term "associative array" don't have
those pre-conceptions.

In what sense?

Instead of just arguing over terminology and being anal retentive when you
_KNOW_ what the intent of the question is, try to provide a more helpful
answer instead.

We all know that you know the inner working of javascript better than most
people in the world, Richard. You can stop trying to prove that. You have
the opportunity to work long hours exclusively on javascript coding and
digging deep into the language. Most people will never have such an
opportunity. So instead of using your knowledge to belittle people and
constantly point out minor errors in terminology and language quirks, it
would be far more helpful to most if you could bridge the gap between a
typical person's understanding of javascript (given limited exposure to the
language, limited time to work on it, and often a very specific task to
complete) and a deeper more correct understanding and use of the language.

When you see someone ask "How can I implement an associative array in
javascript" you shouldn't think "what an idiot, there are no associative
arrays in javascript because that term implies X, Y, and Z, and there are
specific non-arbitrary keys that will cause problems!". Instead, think "what
he probably wants is a simple way to store key/value pairs. I'll explain how
to use a simple Object but also warn of some behaviors and quirks that might
confuse him if he happens to trip on them."

That would be more helpful. Just MO.

 

[Michael Winter]

[MW] Since when has Wikipedia been an authority on the language?
[BVdD] Maybe the Netscape javascript manual then ?

[MW] That still wouldn't automatically eliminate the misuse of terminology.

Sun ?
http://java.sun.com/javascript/ajaxinaction/Ajax_in_Action_ApB.html

"The JavaScript object is essentially just an associative array,
with fields and methods keyed by name."

The phrase "is essentially" indicates a simplification, not an
equivalence, and that would be fine if a more accurate explanation
occurred later. Unfortunately, that doesn't happen.

By the way, Richard, it seems that Jim was given the credits in that
book for the closures article in the FAQ notes, not you. It seems quite
shocking that the authors can misread: "Written by Richard Cornford."


I am not opposed to the use of terms that may ease a programmer from one
language into another, but when /only/ those terms are used to provide
an explanation, it leaves room for confusion and the creation of
misconceptions. How many times have you seen script authors write:

var map = new Array();

map['key'] = 'value';

as though any of the array-like syntax actually means anything? That is,
when:

var map = {}; // or: new Object();

map.key = 'value';

or:

var map = {
key : 'value'
};

would do just as well. I've seen it a lot, and it stems from the
misunderstanding of the nature of objects in ECMAScript. It isn't
difficult to accept that objects can have dynamically-assigned
properties; one doesn't need to turn to concepts in other languages to
describe that feature.

[snip]

This smells like language fetishism - indices or keys are common
names to describe this kind of referencing.

When used in the right context, yes. However, as the object in question
wasn't an associative array, the terms don't apply.

Doesn't matter how it's implemented internally, ...

At what point in this thread have I mentioned internal implementations?

[snip]

I did read the archives, and, as you probably know, it's a
controversial subject.

Given that I've read all of the discussions on the subject from the past
three years or so, and participated in several of them, yes, I'm aware.

But if Wikipedia, Netscape, Microsoft, Sun (and probably more) all
mention associative arrays in such clear terms, I find the "official"
comp.lang.javascript point of view very questionable.

Evidentially, but that seems to be because you fail to recognise, or
refuse to acknowledge, the consequences of describing the language in a
potentially misleading way.

If there was a clear benefit to using the term, or if it really did
apply, I could understand your persistence in this matter. As things
stand, though, I do not.

Mike

 

[Richard Cornford]

And who is to make this definition?

I am inviting Bart Van der Donck to attempt to write the definition. I
am doing so in order that he discovers for himself that any detention
that attempts to discriminate between things that are associative
arrays and things that are not is going to put the javascript object in
the _not_ associative array side.

You?

I have suggested a starting point, but inevitable it puts the
javascript object outside of the categorisation.

Because clearly the common
understanding used by Microsoft,

Microsoft? You are joking?

Netscape, Sun, etc is different than yours.

I have not seen any clear statement from any as to what an associative
array is.

And I would argue that their opinions carry more weight than
yours, even if you are technically more correct.

You probably would.

The difference is, you're looking to define something with absolute
certainty,

No, I am looking to demonstrate that any attempt to pin down what an
associative array is, in such a way as to exclude things that are not
associative arrays, will exclude the javascript object. The final
definition does not have to be complete, absolute or definitive. It is
the exercise of seeking it that will make my point for me.

whereas the term "associative array" is often casually used to
refer to "an object holding key/value pairs".

So that would be a definition that does not exclude the Java Vector
(which is an object that really should not be categorised as an
associative array). Do you see why I am doing this yet? You can have
your casual definition that may include javascript objects, but it will
be so loose as to be useless as things will be included that really
should not be called associative arrays.

The question that remains to be answered is whether there is a
discriminating definition of an associative array that excludes things
that should not be included like the Java Vector but can accommodate
the javascript object. I will not be you who will be proposing such a
discriminating definition.

Even if you disagree with the common use of the
term, you can't just choose to ignore it.

I can point out that it is so loose that it includes things that most
people would never accept as reasonably categorised "associative
arrays".

That's why I put it in quotes. Meaning, similar to but not identical
to Reserved Words. And I knew you would object.

Your attribution of meaning to English is sometimes extremely odd.

Maybe they are your pre-conceptions.

What are my pre-conceptions?

Maybe most people looking for a simple key/value pair
construct and using the term "associative array" don't have
those pre-conceptions.

Maybe most don't (who could say), but the many who do are the ones
being harmed by the inappropriate use of the term in association with
javascript objects. It is, after all, the consequences of their
misconceptions that motivates people to post the questions to the group
that give the impression that "associative array" thinking is a problem
causer when applied to javascript objects.

Instead of just arguing over terminology

So the incoherent sentence is not going to be clarified?

and being anal retentive when you _KNOW_ what the
intent of the question is, try to provide a more helpful
answer instead.

Why don't you? Except maybe given that previous proposed response, its
incoherent nature and your mercenary attitude towards English meaning,
you couldn't be much help in improving anyone's understanding anyway.

When you see someone ask "How can I implement an associative
array in javascript" you shouldn't think "what an idiot, there are no
associative arrays in javascript because that term implies X, Y, and
Z, and there are specific non-arbitrary keys that will cause
problems!".

Is that what I would think? Surly if someone asks how to implement an
associative array in javascript the one assumption that can be made is
that they do not believe that Javascript already has associative
arrays, else the question would be redundant?

Instead, think "what he probably wants is a simple way to
store key/value pairs.

No. If someone asks how to implement an associative array in javascript
I am going to assume that they want to be able to store any value under
an arbitrary string key, retrieve any stored values using that key and
remove the key and its corresponding value form that storage. The
simplicity/complexity of the end result is a product of what it would
have to do, not be pre-supposed by the fact that the question was
asked.

I'll explain how to use a simple Object but also warn of some
behaviors and quirks that might confuse him if he happens to
trip on them."

Right, assume the questioner doesn't really want what they are asking
for and suggest something that will only 'mostly work'.

That would be more helpful. Just MO.

And if they really wanted an associative array, and the ability to use
arbitrary keys safely, you will have wasted your own time, their time,
and possible their development effort as they go off down a dead end
and then work their way back to where they started.

There a no blanket prescription for 'more helpful'. If a question is
asked in a way that informs the reader of the context in which it is
asked it is likely better answered than if not. As soon as we are in
the world of assumptions you cannot tell if a simple quick hack is will
be most appropriate, or a pending disaster.

Richard.

 

[Matt Kruse]

No, I am looking to demonstrate that any attempt to pin down what an
associative array is, in such a way as to exclude things that are not
associative arrays, will exclude the javascript object.

Wouldn't a definition of an associative array necessarily exclude everything
not in the definition? Isn't that the whole point of a definition?

So that would be a definition that does not exclude the Java Vector
(which is an object that really should not be categorised as an
associative array).

Try this:

"An associative array is a collection of unordered values/objects which
allows for the storage and retrieval of a value/object [Value] using a
user-defined value/object [Key] as the only storage/retrieval criteria, such
that retrieving a Value stored for a given Key will return the Value
previously stored for the given Key."

That would include the javascript Object, exclude js Array, and exclude
Vector (since both are ordered). It doesn't say the object cannot have
additional properties of its own, or that retrieving keys which were not
stored would be required to return nothing, or that the user-defined keys
may be completely arbitrary. If you expect those to be part of a definition,
maybe you have too many pre-conceptions about associative arrays.

So the incoherent sentence is not going to be clarified?

Extremely maybe.

Why don't you? Except maybe given that previous proposed response, its
incoherent nature and your mercenary attitude towards English meaning,
you couldn't be much help in improving anyone's understanding anyway.

Do you completely lack a personality, or does it simply not come through in
text?

Surly if someone asks how to implement an
associative array in javascript the one assumption that can be made is
that they do not believe that Javascript already has associative
arrays, else the question would be redundant?

No, they are probably just seeking the language-specific implementation of
the concept. Much like someone new to VB may not find the Dictionary object
but they do know what they want.

No. If someone asks how to implement an associative array in
javascript I am going to assume that they want to be able to store
any value under an arbitrary string key, retrieve any stored values
using that key and remove the key and its corresponding value form
that storage.

Why do you assume a string key? Why don't you assume they want to key based
on any arbitrary Object like in Java? Your assumptions seem to be just those
required to arrive at your conclusion.

 

[Richard Cornford]

Wouldn't a definition of an associative array necessarily exclude
everything not in the definition? Isn't that the whole point of a definition?

Yes, but would any given definition exclude all of those things that
are evidently not associative arrays and include all those things that
are?

So that would be a definition that does not exclude the Java Vector
(which is an object that really should not be categorised as an
associative array).

Try this:

"An associative array is a collection of unordered values/objects which
allows for the storage and retrieval of a value/object [Value] using a
user-defined value/object [Key] as the only storage/retrieval criteria, such
that retrieving a Value stored for a given Key will return the Value
previously stored for the given Key."

You have left "user-defined value/object [key] so open that it is not
possible to eliminate many objects. If "user-defined" is allowed to
include, say, a limited set of non-arbitrary strings then many hundreds
of objects could start to qualify. Suppose a 'user' (read programmer)
defines a Java class has two named public instance members of Object
type, then you can regard the names of those members as keys with witch
you can store values in the object, and retrieve them from it. The
result is unordered, can have values stored/ retrieved using those keys
as the only criteria and the given key will return the value previously
sorted with that key.

That would include the javascript Object,

That would depend on what you mean by "user-defined value/object
[key]". If "user-defined" is intended to indicate that the user may
define anything (or anything reasonable in the context (so any string
key in the case of javascript objects)) then the fact that you cannot
reliably store values in objects using any key, or subsequently
retrieve those values form objects using the same key, then javascript
objects do not qualify.

exclude js Array,

As JS Arrays are JS Objects, how does it manage that?

and exclude
Vector (since both are ordered).

Ah, you have explicitly put "a collection of unordered values/objects"
in your definition so that you can exclude Vectors. But for that to
work you have to exclude any associative arrays that are ordered in any
way, and this very thread demonstrates that consistent ordering in
enumeration is not only something that is expected of associative
arrays but also a feature of javascript object implementations. That
is, javascript object properties have been demonstrated to be available
in the order in which they were added to the object, and the OP reports
an associative arrays that orders its keys alphabetically.

It doesn't say the object cannot have additional properties
of its own, or that retrieving keys which were not
stored would be required to return nothing,

Which is a considerable compromise.

or that the user-defined keys may be completely arbitrary.

If you are not allowed all permutations of possible keys then only
being allowed as few as two string keys qualifies, and thousands of
objects suddenly become associative arrays. You have really just fudged
the question of the keys.

If you expect those to be part of a definition,
maybe you have too many pre-conceptions about
associative arrays.

I suspect that if you asked most of the people who use associative
arrays they would find the idea of being able to use some keys of one
type, and not others of the same type, completely alien.

Extremely maybe.


Do you completely lack a personality, ...

Ahh, personal abuse.

No, they are probably just ... .

Be cautions of accusing others of making assumptions when you are so
happy to do so yourself.

Why do you assume a string key?

If anything is stored as a property of an object in javascript it is a
string that is used as the key.

Why don't you assume they want to key based
on any arbitrary Object like in Java?

That would be more of a HashTable than an associative array. When the
question of implementing HashTable in javascript has arisen I have
explained how to key them with objects. To date nobody has expressed an
interest in implementing an associative array as such.

Your assumptions seem to be just those
required to arrive at your conclusion.

At least the end result would be consistent rather than just "mostly
works".

Richard.

 

[Lasse Reichstein Nielsen]

Property names are only strings in the sense of being sequences of zero
or more characters.

The actual property names of objects can be any value (in ECMAScript
3ed), but the language itself only gives access to operations that
use string values as property names. These are string in the sense
of being values of the String type (typically results of the ToString
function).

If a property of an object is accessed as:-

var val = obj.someProperty;

- the - someProperty - is not a string (in the sense of being a
javascript string primitive or String Object), it is an Identifier.

True, but the identifier is not the property name being used to
access the objects property. A string value containing the same
characters is.

The sense in which property names are strings is only that in a bracket
notation property accessor any expression inside the brackets is
type-converted into a string before the resulting is used to look up
the property on the object.

True. The [[Get]] and [[Put]] functions doesn't make any restrictions
on what can be a "property name". It's not possible with pure ECMAScript
to have those methods called with anything but a string, though.

/L

 

[Bart Van der Donck]

I am inviting Bart Van der Donck to attempt to write the definition. I
am doing so in order that he discovers for himself that any detention
that attempts to discriminate between things that are associative
arrays and things that are not is going to put the javascript object in
the _not_ associative array side.
[...]

Can find myself in 2 'official' definitions from the N.I.S.T.:

"A collection of items that are randomly accessible by a key, often a
string."
(http://www.nist.gov/dads/HTML/assocarray.html)

"An abstract data type storing items, or values. A value is accessed by
an associated key. Basic operations are new, insert, find and delete."
(http://www.nist.gov/dads/HTML/dictionary.html)

Surprisingly broad, isn't it ? But I think this should be about as far
as you can go; further specifications quickly lead to language-specific
implementations.

 

[Richard Cornford]

I am inviting Bart Van der Donck to attempt to write the
definition. I am doing so in order that he discovers for
himself that any detention that attempts to discriminate
between things that are associative arrays and things that
are not is going to put the javascript object in the _not_
associative array side.
[...]

Can find myself in 2 'official' definitions from the N.I.S.T.:

"A collection of items that are randomly accessible by a key,
often a string."
(http://www.nist.gov/dads/HTML/assocarray.html)

"An abstract data type storing items, or values. A value is
accessed by an associated key. Basic operations are new,
insert, find and delete."
(http://www.nist.gov/dads/HTML/dictionary.html)

Surprisingly broad, isn't it ?

That doesn't matter. The question is still just whether these
definitions include things that should not be regarded as associative
arrays, such as the Java Vector, or exclude the javascript object.
Neither excludes the Java Vector, so are not really that discriminating.
Being able to label something that is conceptually an array as an
"associative array" is quite a price to pay in order to label something
that should not be thought of as one an associative array.

Where the second says "an associated key" it ether means 'any associated
key' and so excludes the javascript object, as it cannot store and
access values (or items) by any associated key, or delete them (That is,
some key will not store, cannot retrieve stored values (as they were
never stored) and cannot be deleted), or "an associated key" means 'a
specific associated key', and any Java class that has a public member is
included.

So either an associative array is so broad a concept that the label
could be applied to all sorts of things (so probably better not used at
all), or it does not apply to javascript objects.

But I think this should be about as far as you can
go; further specifications quickly lead to
language-specific implementations.

I don't think that is true. A much more specific definition could be
written. I still think the answer lies in the nature of the keys; that
if of a type then all values of that type, and if of many types all
values of all allowed types (i.e. if a string then any arbitrary
character sequence as a string). The key is itself an aspect of the
data, and so cannot be more restricted than the data. It is a
significant aspect of this type of storage that you don't need to know
the actual value of the key when you use it (even if you may need to
know its type, or that it is of the right type(s)). It is that aspect of
the issue that excludes the javascript object, and making the definition
of a key so vague as to avoid making it obvious that the javascript
object is excluded just makes the concept so loose as to allow all sorts
of things to be included.

Another approach to a reasonable definition of an associative array may
be to look that those objects in languages that can be agreed to have
them and see what is common among them.

Richard.

 

[Randy Webb]

Richard Cornford said the following on 8/23/2006 6:49 AM:

Bart Van der Donck wrote:


Really? How many associative array implementations will not let you
store a value using an arbitrary key? How many will return a value that
was never stored? How many will return a value that differs from the
one stored? How many will not let you remove a key value pair that you
have previously stored.

And, how many associative array implementations don't increase the
..length property of the array when you add an element?

 

[Matt Kruse]

And, how many associative array implementations don't increase the
.length property of the array when you add an element?

I would put that into the "doesn't matter" category, as I don't think it
should be a requirement of an associative array to have a size or length
property/accessor.

Perhaps what should be added to my proposed definition is that any
associative array should have a way to retrieve a list of all keys. Which,
of course, you can do with a javascript Object.

 

[Richard Cornford]

I would put that into the "doesn't matter" category, as I don't
think it should be a requirement of an associative array to
have a size or length property/accessor.

Perhaps what should be added to my proposed definition is that
any associative array should have a way to retrieve a list of
all keys. Which, of course, you can do with a javascript Object.

Not if a key is defined as something that can be used to reference an
associated value held by the object, as only enumerable properties would
be listed and the names of the non-enumerable properties would still
qualify as keys. (That is, if you want to allow pre-defined/pre-existing
key/value pairs, as you must if the javascript object is to be included
in the category, the keys for those properties should be included in a
list of "all keys" or it is not a list of all of the keys.)

Richard.