array.["property"]

[josh]

Hi all,
what does it meaning that strange sintax (look at the object ?

if I have i.e. array.length I can use array.["length"] and is it
IE/Firefox compatible??

 

[Lee]

josh said:

Hi all,
what does it meaning that strange sintax (look at the object ?

You seem to mean "look at the subject", and that's a nuisance with
some newsreaders. Don't ask people to read the subject while
they're reading the message.

if I have i.e. array.length I can use array.["length"] and is it
IE/Firefox compatible??

No, you can't use that syntax in any browser, but you should be
able to use: array["length"] in any. There's no "dot".

You can use this notation to access attributes of any Object.


--

 

[adamraney]

Try it without the dot:

array['length'] is equivilant to array.length.

 

[Martijn Saly]

Hi all,
what does it meaning that strange sintax (look at the object ?

if I have i.e. array.length I can use array.["length"] and is it
IE/Firefox compatible??

array["length"] is equivalent to array.length

In javascript, an object is the same as an associative array, which
makes the formal difference between arrays and objects blurry.

This is defined by the ECMA-262 standard, and is thus compatible with
all browsers and all javascript engines.

array.["length"] (mind the dot) is a syntax error. Some javascript
parsers *may* tolerate it but you *shouldn't* count on it.

 

[josh]

Martijn Saly ha scritto:

In javascript, an object is the same as an associative array, which
makes the formal difference between arrays and objects blurry.

please explain better what it mean 'makes the formal difference between
arrays and objects blurry'

 

[Martijn Saly]

Martijn Saly ha scritto:



please explain better what it mean 'makes the formal difference between
arrays and objects blurry'

I mean to say that an object is so similar to an array that it becomes
difficult to explain what an object is compared to an array.

Consider an *object* with a length property. It can be accessed in two ways:

obj.length
obj["length"]

An *array* shows the same behavior, its second element can be accessed
in two ways:

array[1]
array.1


I would say the only difference is the way they are constructed. An
objects goes like one of these:

var obj = {foo: bar};
var obj = new Something(args);

but an array constructor producing an array with 2 elements goes like this:

var array = [foo, bar];


So you see, I can't really tell the functional difference between an
object and an array, other then the methods that come with an array.

 

[Randy Webb]

Martijn Saly said the following on 11/21/2006 9:29 AM:

Hi all,
what does it meaning that strange sintax (look at the object ?

if I have i.e. array.length I can use array.["length"] and is it
IE/Firefox compatible??

array["length"] is equivalent to array.length

In javascript, an object is the same as an associative array, which
makes the formal difference between arrays and objects blurry.

NO! An Object in JS is *NOT* an associative array. JS doesn't have an
associative array - period.

 

[Matt Kruse]

NO! An Object in JS is *NOT* an associative array. JS doesn't have an
associative array - period.

Must this continue to be said?

The fact is, there is no one definition for what an "associative array" is.
So how can you say that a js Object is not one?

Depending on how you choose to define an "associative array", an Object in
javascript can most certainly be described as one.

IMO, most programmers looking for an "associative array" in javascript are
in fact looking for what an Object offers. Despite its quirks and special
cases, I've never met or heard of a single person who was looking for an
associative array who was not satisfied using an Object.

I propose:

<FAQENTRY>

Q: How do I implement an Associative Array in Javascript?

A: The term Associative Array is vague, having different meanings in
different languages, so it's impossible to know what behavior is expected of
an Associative Array implementation. However, Javascript's Object() can
behave as a key/value storage object, which is the minimum that most people
expect from an Associative Array implementation.

A simple example:

var assocArray = {};
assocArray["key"] = "value";
alert(assocArray["key"]);
for (var key in assocArray) {
alert(key + " = " + assocArray[key]);
}

Using a Javascript Object() as an Associative Array comes with the following
limitations:
1. Keys must be strings, not arbitrary objects.
2. Some keys are invalid, because Javascript's Object has built-in
properties that cannot be over-written.
3. Some keys will exist by default because of Object's built-in properties.
These will not be enumerated in for..in loops but can be directly accessed.
4. No method or property exists by default to retrieve the size - or number
of keys - currently stored.

</FAQENTRY>

 

[RobG]

Martijn Saly ha scritto:



please explain better what it mean 'makes the formal difference between
arrays and objects blurry'

A javascript Array *is* an Object, it has a special length property (it
is self-adjusting and has a value that is always one higher than the
highest index) and a bunch of extra methods - push(), split(), pop(),
etc.

Javascript does not have "associative arrays". Its native Object uses
name:value pairs that make it similar to an associative array that can
be found in other languages, but it lacks features that might be
expected of an associative array.

 

[Richard Cornford]

Must this continue to be said?

While it remains true (which will be far beyond the next version of ECMA
262) it should be said and it will be said.

The fact is, there is no one definition for what an
"associative array" is. So how can you say that a js
Object is not one?

Where associative arrays exist, and use that name, a common feature is
the ability to use arbitrary keys (possibly restricted to arbitrary
string keys) to store and retrieve values. It is not safe to use
arbitrary property names with javascript objects, only sets of names
that have known characteristics (such as string keys consisting of only
upper case letters). Failing to appreciate that important distinction
risks writing something that may happily operate as expected (and even
do so for a very extended period of time) and then suddenly find itself
encountering a problematic key (that someone has introduced into the
system). That sort of problem may be hard to spot, hard to reproduce,
hard to identify, and may even only effect one language implementation.
But can be avoided entirely by thinking about javascript objects as the
things that they are (dynamically modifiable collections of name value
pairs) and not as empty vessels in which arbitrarily named values pairs
can be placed.

Depending on how you choose to define an "associative array",
an Object in javascript can most certainly be described as one.

But, as has been demonstrated in the past, such definitions of
"associative array" do not exclude objects that are obviously not
associative arrays.

IMO, most programmers looking for an "associative array" in
javascript are in fact looking for what an Object offers.

That is probably true (as most specific cases have sufficient
constraints on the property names employed for it to be possible to
determine whether they are a safe set or not). But it is also evident
that many javascript novices have been told that they have an
"associative array" in the javascript object and then had their
expectations disappointed by an object that does no more and no less
than it was intended to do (be amenable to runtime modification of (most
of) its (actual or potential)named properties).

Despite its quirks and special cases, I've never met or
heard of a single person who was looking for an associative
array who was not satisfied using an Object.

I have seen some examples posted to the group, but as I said the issues
of non-safe names may not be easy to spot so following a recommendation
to use a javascript object as an "associative array" may appear to solve
many more problems than it really does in the long term.

However, it is a pity that people "looking for an associative array"
don't state their problem in more comprehensive terms, as 'I want to
store values under key that all start with a decimal digit, or are all
uppercase" could have people pointed straight to the javascript object
as completely appropriate, while 'I want to store values using
completely arbitrary keys' could have them directed towards the many
'safe hashtable' implementations that have appeared in the group over
the years.

I propose:

<FA****RY>

Q: How do I implement an Associative Array in Javascript?

A: The term Associative Array is vague, having different
meanings in different languages, so it's impossible to
know what behavior is expected of an Associative Array
implementation. However, Javascript's Object() can behave
as a key/value storage object, which is the minimum that
most people expect from an Associative Array implementation.

<snip>

I don't think storing key value pairs in the minimum that people expect
from an associative array. There are hundreds of Java objects with named
public members in which you can store a value, and so store key value
pairs (the key may be totally pre-defined and the value type constrained
but still storing a value using a key is what assigning to such a member
constitutes). A reasonably define "associative array" would have limited
constraints on the number of key, value pairs that could be stored, and
the keys would be expected to be arbitrary.

It makes much more sense to tell people that there are no associative
arrays in javascript and then tell them what can be achieved with what
there is, and how it may be achieved.

Richard.

 

[Randy Webb]

Matt Kruse said the following on 11/21/2006 3:42 PM:

Must this continue to be said?

As long as people incorrectly state that the JS object is an associative
array, then yes, it must continue to be said.

Would you have a problem with someone defending the use of eval in a
manner such as this:


var formName = "myForm";
var elementName = "myInput";
var thisVar =
eval('document.forms['+formName+'].elements['+elementName+'].value');
//I might have a syntax error in there but you get my point.


Simply because "It comes close to being what the person wanted"? Of
course not. And leading people to believe JS has an AA is just as bad as
telling them the use of eval is "OK" above because it's "close to what
you wanted".

JS doesn't have an associative array, it can be closely emulated -
within restrictions - but it doesn't have one.

 

[RobG]

Matt Kruse wrote:
[...]

IMO, most programmers looking for an "associative array" in javascript are
in fact looking for what an Object offers. Despite its quirks and special
cases, I've never met or heard of a single person who was looking for an
associative array who was not satisfied using an Object. [...]
Using a Javascript Object() as an Associative Array comes with the following
limitations:
1. Keys must be strings, not arbitrary objects.
2. Some keys are invalid, because Javascript's Object has built-in
properties that cannot be over-written.
3. Some keys will exist by default because of Object's built-in properties.
These will not be enumerated in for..in loops but can be directly accessed.
4. No method or property exists by default to retrieve the size - or number
of keys - currently stored.

The problem with that approach is that you will have a never-ending
list of limitations - or at least people will want to keep adding to
whatever list you have. An exhaustive list would be very, very long
and would need to cover common features of associative arrays that
aren't provided by the built-in Object.

Therefore, I think Richard's approach of "there is no javascript
associative array, but here's how you can use an Object to implement
some of the features of an associative array" is better, though it
still requires a list of caveats in regard to property names and access
as you've posted above.

I think it's worth adding that:

5. for..in iterates over all the properties of the object and its
prototype chain

6. You can't create non-enumerable properties.

 

[Matt Kruse]

Would you have a problem with someone defending the use of eval in a
manner such as this:

That is in fact valid script. There just happens to be a better, less
error-prone, faster way to accomplish the same thing.

JS doesn't have an associative array, it can be closely emulated -
within restrictions - but it doesn't have one.

That implies that there is an agreed upon definition of "associative array"
by which javascript's Object could be judged. There is no agreed-upon
definition. In fact, many of the definitions you'll find floating around -
even from reputable sources - would _include_ the js Object, not exclude it.

An "associative array" is a concept - an enumerable data container that is
keyed by a name rather than an index, making data possible retrieval without
scanning an array of values. Obviously we all agree that using the
javascript Object places limitations on how you use it. And we're kind of
playing a semantics game. But let's be practical - the goal of a FAQ or
answering questions is to help people. And when they ask for associative
arrays, nine times out of ten they are looking for a simple name/value data
container, and the solution that works best for them is a simple Object.
Let's not make that solution so obfuscated that readers aren't sure that
they are getting what they're asking for.

 

[John G Harris]

Using a Javascript Object() as an Associative Array comes with the following
limitations:
1. Keys must be strings, not arbitrary objects.
2. Some keys are invalid, because Javascript's Object has built-in
properties that cannot be over-written.
3. Some keys will exist by default because of Object's built-in properties.
These will not be enumerated in for..in loops but can be directly accessed.

3.1 If you are using someone else's library, e.g prototype.js, some keys
might have been inserted by the library, and these will be enumerated in
for..in loops whether you want it or not.

4. No method or property exists by default to retrieve the size - or number
of keys - currently stored.

If you need the size you have to program it yourself.

</FAQENTRY>

John

 

[John G Harris]

It makes much more sense to tell people that there are no associative
arrays in javascript

If you rephrased that to say that there are no general purpose
associative arrays in the javascript language it would save a lot of
argument.

It is obvious to any javascript engine designer that an object is an
associative array with some extra data values attached. However, what's
handed over to javascript programmers is a polluted associative array.

and then tell them what can be achieved with what
there is, and how it may be achieved.

John

 

[Richard Cornford]

Richard Cornford writes

If you rephrased that to say that there are no general
purpose associative arrays in the javascript language
it would save a lot of argument.

What is the difference between 'not an associative array' and 'not a
general purpose associative array'? Being general is what an associative
array is expected to do. Otherwise where would it be possible to draw a
line between an object in which it as possible to store only one
key/value pair using just a single key (something that hardly anyone
would regard an associative array) and an associative array?

It is obvious to any javascript engine designer that an
object is an associative array

Or a hash table, or something similar (JScript has been observed to be
using list-like structure for its objects).

with some extra data values attached. However,
what's handed over to javascript programmers is a
polluted associative array.

<snip>

But what you are calling pollution here is precisely what makes it
inappropriate to speak of the result as an associative array. It is an
object with particular characteristics, which may be suited to the
storage of key/value pairs where the keys are in a 'safe set' but are
not suited to the general storage of key value pairs where the keys are
arbitrary.

The issue with the name "associative array" is that it brings with it a
baggage of expectations from language where associative arrays are
available. Those other associative arrays are general, and so the
expectation introduced is that the javascript object will be general,
but it just isn't.

Richard.

 

[Matt Kruse]

Being general is what an
associative array is expected to do. Otherwise where would it be
possible to draw a line between an object in which it as possible to
store only one key/value pair using just a single key (something that
hardly anyone would regard an associative array) and an associative
array?

An associative array can have its keys be unknown until runtime. An object
(in the java sense) cannot.
Therefore, to be an associative array, the method must allow the keys to be
uknown until runtime.

The issue with the name "associative array" is that it brings with it
a baggage of expectations from language where associative arrays are
available.

The "baggage" is not consistent between people, since there is no one
definition of "associative array".

Those other associative arrays are general, and so the
expectation introduced is that the javascript object will be general,
but it just isn't.

You are deciding what others' expectations are, but I don't think that
everyone shares the same expectations.

 

[Bart Van der Donck]

An "associative array" is a concept - an enumerable data container that is
keyed by a name rather than an index, making data possible retrieval without
scanning an array of values. Obviously we all agree that using the
javascript Object places limitations on how you use it. And we're kind of
playing a semantics game. But let's be practical - the goal of a FAQ or
answering questions is to help people. And when they ask for associative
arrays, nine times out of ten they are looking for a simple name/value data
container, and the solution that works best for them is a simple Object.
Let's not make that solution so obfuscated that readers aren't sure that
they are getting what they're asking for.

Your post proves a lot of common sense IMO.

One should rather speak in terms of "forms of associative arrays"
across languages. It's not a yes-or-no discussion. It's about the
functionality and behaviour that are possible and that are typical for
such variables. Their *behaviour* defines how they're intended to work,
which is clearly "like an associative array". Their particularities do
not affect that definition.

One should not discuss this matter on a narrow technical level, that's
only a red herring. One should only take synthetic and conceptual
arguments into account.

He who claims that "associative array" is not a justified term in
javascript, must also claim that the term is not justified in much more
languages.

 

[Bart Van der Donck]

But what you are calling pollution here is precisely what makes it
inappropriate to speak of the result as an associative array. It is an
object with particular characteristics, which may be suited to the
storage of key/value pairs where the keys are in a 'safe set' but are
not suited to the general storage of key value pairs where the keys are
arbitrary.

Exactly. You can say at most that javascript's implementation of
"associative arrays" is not that good. This might be your opinion and
that of others, but it's still an opinion. That doesn't touch the core
of the discussion. One can say that is good or bad weather, but it
remains weather.

The issue with the name "associative array" is that it brings with it a
baggage of expectations from language where associative arrays are
available. Those other associative arrays are general, and so the
expectation introduced is that the javascript object will be general,
but it just isn't.

You can not come from language X and then expect "associative arrays"
to work the same in language Y. It would be a wrong and dangerous
attitude for a programmer to have such expectations.

 

[Richard Cornford]

Exactly. You can say at most that javascript's implementation of
"associative arrays" is not that good. This might be your
opinion and that of others, but it's still an opinion.

It is not my opinion (and I doubt that many others hod it). It is
ridiculous to speak of a javascript object as an associative array that
is "not that good". A javascript object is a very good javascript
object, and it is that in every implementation.

That doesn't touch the core of the discussion. One can say
that is good or bad weather, but it remains weather.

You are the one proposing labelling javascript objects as good or bad.

Consider an alternative analogy; suppose you have sizeable section of
tree trunk and someone carves a figurative sculpture out of it. Do you
know describe the result as a bad section of tree trunk because it is
now not practical to manufacture floorboards from it? The sculpture
certainly is not a good section of tree trunk, but that is not the
criteria that is applicable.

In the implementation language the object employed for the javascript
object may be an associative array (or a hash table, or a list, or
whatever facilitates what is necessary for a javascript object) but once
that underlying object has been used to manufacture a javascript object
a series of irreversible changes in the object have transformed it into
something that no longer has the qualities of an associative array.
Specifically; it no longer has the quality that all possible (therefor
arbitrary) keys are treated equally. The end result very simply is not
an associative array (good, bad or otherwise).

You can not come from language X and then expect
"associative arrays" to work the same in language Y.

Should not, but you certainly can. A fact that a very long succession of
questions asked in this group stand testimony to.

It would be a wrong and dangerous attitude for
a programmer to have such expectations.

Yes it is a mistake, but it is not a mistake that will be discouraged by
speaking of an object that has very specific qualities of its own as an
"associative array".

Richard.