468,139 Members | 1,454 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,139 developers. It's quick & easy.

array.["property"]

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??

Nov 21 '06 #1
30 2598
Try it without the dot:

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

On Nov 21, 8:09 am, "josh" <xdevel2...@yahoo.comwrote:
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??
Nov 21 '06 #2
josh wrote:
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.
--
Martijn Saly
Nov 21 '06 #3
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.
--

Nov 21 '06 #4

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'

Nov 21 '06 #5
josh wrote:
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'
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.

--
Martijn Saly
Nov 21 '06 #6
Martijn Saly said the following on 11/21/2006 9:29 AM:
josh wrote:
>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.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Nov 21 '06 #7
Martijn Saly said the following on 11/21/2006 10:21 AM:
josh wrote:
>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'

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];
Or like this:

var myArray = new Array(foo,bar)

or like this:

var myArray = new Array();
myArray[0] = foo
myArray[1] = 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.
You can give an Object a property called "length" and it can be unique
and meaningful to the programmer. That can not be said for an Array as
it has a very specific use of the length property.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Nov 21 '06 #8

josh wrote:
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'
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.
--
Rob

Nov 21 '06 #9
Randy Webb wrote:
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>

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Nov 21 '06 #10
Matt Kruse wrote:
Randy Webb wrote:
>NO! An Object in JS is *NOT* an associative array. JS doesn't
have an associative array - period.

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.
Nov 22 '06 #11
Matt Kruse said the following on 11/21/2006 3:42 PM:
Randy Webb wrote:
>NO! An Object in JS is *NOT* an associative array. JS doesn't have an
associative array - period.

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.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Nov 22 '06 #12

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

Nov 22 '06 #13
Randy Webb wrote:
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.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Nov 22 '06 #14
In article <ej*********@news4.newsguy.com>, Matt Kruse
<ne********@mattkruse.comwrites

<snip>
>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 Harris
Nov 22 '06 #15
In article <ek*******************@news.demon.co.uk>, Richard Cornford
<Ri*****@litotes.demon.co.ukwrites

<snip>
>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
--
John Harris
Nov 22 '06 #16
John G Harris wrote:
Richard Cornford writes
<snip>
>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.
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.
Nov 26 '06 #17
Richard Cornford wrote:
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.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Nov 27 '06 #18
Matt Kruse wrote:
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

Nov 27 '06 #19
Richard Cornford wrote:
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.

--
Bart

Nov 27 '06 #20
Bart Van der Donck wrote:
Richard Cornford wrote:
>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.
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).

>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.
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.
Nov 27 '06 #21
Matt Kruse wrote:
Richard Cornford wrote:
>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.
Not true; java.lang.reflect - allows the assigning of values to object
properties without the need to know the names until runtime.
Therefore, to be an associative array, the method must allow
the keys to be uknown until runtime.
Unknown until runtime implies that the keys be arbitrary. However,
insisting that an associative array be capable of handing all arbitrary
keys equally excludes the Java objects in question (and the javascript
object), while insisting on the keys being unknown until runtime does
not exclude those Java objects.
>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".
It doesn't matter if there expectations are not consistent if it is
extremely rare that they are helpful to them when trying to understand
javascript objects.
>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.
I don't think they share the same expectations, but I have observed how
expectations relating to associative arrays have stood in the way of
people understanding what a javascript object is. Virtually any
expectation can do that.

Richard.
Nov 27 '06 #22
Richard Cornford said the following on 11/27/2006 6:36 PM:

<snip>
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).
Can you quote a reference that says an Associative Array has to be able
to have arbitrary keys?

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Nov 27 '06 #23
"Randy Webb" wrote:
Richard Cornford said the following on 11/27/2006 6:36 PM:
>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).

Can you quote a reference that says an Associative Array has
to be able to have arbitrary keys?
Why do I need to? Can you cite an example of something that
unambiguously is an associative array that would treat keys of the same
type differently depending on the value of those keys?

Richard.
Nov 28 '06 #24
Richard Cornford said the following on 11/27/2006 8:21 PM:
"Randy Webb" wrote:
>Richard Cornford said the following on 11/27/2006 6:36 PM:
>>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).
Can you quote a reference that says an Associative Array has
to be able to have arbitrary keys?

Why do I need to?
Because it would lend credence to your belief of what one is. But I
didn't expect you to quote a reference.
Can you cite an example of something that unambiguously is an
associative array that would treat keys of the same type differently
depending on the value of those keys?
I am not going to disprove your argument, I asked you to back it up and
you wouldn't. That alone speaks in and of itself Richard.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Nov 28 '06 #25
Richard Cornford wrote:
Matt Kruse wrote:
>An associative array can have its keys be unknown until runtime.
An object (in the java sense) cannot.
Not true; java.lang.reflect - allows the assigning of values to object
properties without the need to know the names until runtime.
"Unknown" was perhaps not the best word for me to choose, if you choose to
be obtuse about it.
How about "An associative array can have its keys be determined and defined
at runtime"?
A Java object cannot have its properties defined at runtime. Reflection has
nothing to do with it.
Unknown until runtime implies that the keys be arbitrary.
No, it does not. That is just a leap of logic used to support your position.
However,
insisting that an associative array be capable of handing all
arbitrary keys
You are the only one insisting this. Once you give up on this point, things
will be easier for you.
I have observed
how expectations relating to associative arrays have stood in the way
of people understanding what a javascript object is.
That's a whole different argument. Certainly, if your goal is to understand
javascript objects, then calling them associative arrays is misleading. But
if your goal is to implement a simple associative array, insisting that
javascript does not have an AA is misleading as well.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Nov 28 '06 #26
Richard Cornford wrote:
"Randy Webb" wrote:
>Can you quote a reference that says an Associative Array has
to be able to have arbitrary keys?
Why do I need to? Can you cite an example of something that
unambiguously is an associative array ...
Circular logic, no?

There is no way to cite an example of something that is "unambiguously" an
associative array, because no definition or requirements exist. And citing
an example that doesn't meet your criteria would certainly make it ambiguous
in your opinion.

I believe that a javascript object is unambiguously an associative array.
Therefore, that's my example.

The fact is, you can look around the web and in programming books all you
want and you won't find many definitions of an associative array that are as
restrictive as yours. Certainly there are many that would include the
javascript Object. So if myself and others are wrong in your eyes, we're
definitely not alone. ;)

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Nov 28 '06 #27
Richard Cornford wrote:
[...] Can you cite an example of something that unambiguously
is an associative array that would treat keys of the same type
differently depending on the value of those keys?
Sure.

#!/usr/bin/perl
use strict;
use warnings;

$ENV{"aKey"} = "aValue"; # (like js' ENV["aKey"] = "aValue")
print "(1) " . $ENV{"aKey"} . "\n";
print "(2) " . $ENV{"SYSTEMROOT"} . "\n";

$INC{"aSecondKey"} = "aSecondValue";
print "(3) " . $INC{"aSecondKey"} . "\n";
print "(4) " . $INC{"strict.pm"} . "\n";

It says:

(1) aValue
(2) C:\WINDOWS
(3) aSecondValue
(4) c:/Perl/lib/strict.pm

I know Perl is not a fair game here, but this is what's going on:
hashes (=associative arrays) %INC, %ENV and %SIG hold special
pre-defined values for certain keys. Other keys are free to be filled
by the programmer.

Does this mean that there are no associative arrays in Perl ? Not at
all. It means that a Perl programmer must be aware of how associative
arrays work in Perl, and that some keys are not available for those
hashes.

Also, Perl hashes know other particularities: no sorting possibilities,
multi-dimensional hashes, (de)referencing to other vars in hash values,
additional forbidden keys from modules, etc.

--
Bart

Nov 28 '06 #28
In article <ek*******************@news.demon.co.uk>, Richard Cornford
<Ri*****@litotes.demon.co.ukwrites

<snip>
>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)
Let's be a bit technical here. 'Associative Array' is an abstract data
type that can be implemented in any way that works.

A 'Hash Table' is a programming construct that could be used in
implementing an associative array. So is a linked list; so is an
ordinary array; so are a variety of tree structures; so is a database if
one is handy (using AJAX perhaps ?). There is evidence that linked lists
are used in javascript objects.

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

Very true. But I still say that
"There are NO associative arrays in javascript"
needs a few extra words to distinguish between the internals of
javascript and the facilities that are available to programmers.
John
--
John Harris
Nov 28 '06 #29
Bart Van der Donck wrote:
Richard Cornford wrote:
>[...] Can you cite an example of something that unambiguously
is an associative array that would treat keys of the same type
differently depending on the value of those keys?

Sure.

#!/usr/bin/perl
use strict;
use warnings;

$ENV{"aKey"} = "aValue"; # (like js' ENV["aKey"] = "aValue")
print "(1) " . $ENV{"aKey"} . "\n";
print "(2) " . $ENV{"SYSTEMROOT"} . "\n";

$INC{"aSecondKey"} = "aSecondValue";
print "(3) " . $INC{"aSecondKey"} . "\n";
print "(4) " . $INC{"strict.pm"} . "\n";

It says:

(1) aValue
(2) C:\WINDOWS
(3) aSecondValue
(4) c:/Perl/lib/strict.pm
If I am reading this correctly we can see two assignments using string
keys which appear to both be successful, and four retrievals using
string keys, which all appear to be equally successful. This does not
demonstrate any treating of keys differently based upon the value of the
key.

I suppose you are suggesting that the second of each pair of retrievals
is treating the keys differently as they have (supposedly) not been
assigned. But that is not reasonable as your code does not show the
instantiation of the objects, or the intervening treatments of them.

What is really needed is a demonstration that writing to a 'significant'
key can fail to assign a value (or that the value will be modified in
the process).
I know Perl is not a fair game here, but this is what's going on:
hashes (=associative arrays) %INC, %ENV and %SIG hold special
pre-defined values for certain keys.
These 'associative arrays' are part of the execution environment, aren't
they? That may be used to argue that they are no longer associative
arrays, but more interfaces to the environment. But I would be more
interested in seeing them reject/modify an assignment before rejecting
the claim that they are associative arrays. As it is I don't see any
evidence of them treating keys differently depending on the actual value
of the key, only evidence that some key/value pairs have been assigned
prior to the object being exposed. And as a result these are not exempts
of associative arrays that would treat keys of the same type differently
depending on the value of those keys.
Other keys are free to be filled
by the programmer.
But can the programmer assign to the system defined keys (without
modification of the value or side effects)?
Does this mean that there are no associative arrays in
Perl ? Not at all.
I have not seen that these objects are unambiguously associative arrays,
though the code you posted does not contradict that, but even if they
were not that could not be extended to saying that Perl had no
associative arrays. But javascript only has one object type, either that
object is an associative array or javascript has no associative arrays,
it is that black and white.
It means that a Perl programmer must be aware of how
associative arrays work in Perl,
Surely it means that Pearl programmers have to be aware that these
particular associative arrays are partly pre-populated with significant
keys?
and that some keys are not available for those
hashes.
Yes, does it have any implications for when they create a new hash from
scratch?
Also, Perl hashes know other particularities: no sorting
possibilities, multi-dimensional hashes, (de)referencing
to other vars in hash values,
None of which help the decision either way.
additional forbidden keys from modules, etc.
But that may be very significant. Can you say more? Or does this only
apply to the special pre-populated hashes you started with?

Richard.
Nov 30 '06 #30
Richard Cornford wrote:
Bart Van der Donck wrote:
Richard Cornford wrote:
[...] Can you cite an example of something that unambiguously
is an associative array that would treat keys of the same type
differently depending on the value of those keys?
Sure.

#!/usr/bin/perl
use strict;
use warnings;

$ENV{"aKey"} = "aValue"; # (like js' ENV["aKey"] = "aValue")
print "(1) " . $ENV{"aKey"} . "\n";
print "(2) " . $ENV{"SYSTEMROOT"} . "\n";

$INC{"aSecondKey"} = "aSecondValue";
print "(3) " . $INC{"aSecondKey"} . "\n";
print "(4) " . $INC{"strict.pm"} . "\n";

It says:

(1) aValue
(2) C:\WINDOWS
(3) aSecondValue
(4) c:/Perl/lib/strict.pm

If I am reading this correctly we can see two assignments using string
keys which appear to both be successful, and four retrievals using
string keys, which all appear to be equally successful. This does not
demonstrate any treating of keys differently based upon the value of the
key.

I suppose you are suggesting that the second of each pair of retrievals
is treating the keys differently as they have (supposedly) not been
assigned. But that is not reasonable as your code does not show the
instantiation of the objects, or the intervening treatments of them.

What is really needed is a demonstration that writing to a 'significant'
key can fail to assign a value (or that the value will be modified in
the process).
#!/usr/bin/perl
use strict;
use warnings;
$SIG{"ABRT"} = "something";
print $SIG{"ABRT"};

It prints "main::something" and not "something".
These 'associative arrays' are part of the execution environment,
aren't they?
Yes, they are. You can somewhat compare %ENV to the 'navigator'-object
in javascript until a certain level.
That may be used to argue that they are no longer associative
arrays, but more interfaces to the environment.
I would say they are both. %ENV is definitely an environmental
informant (hence its name), but %INC or %SIG are not, they hold other
kinds of information that the programmer might be interested in.
But I would be more interested in seeing them reject/modify an
assignment before rejecting the claim that they are associative arrays.
See example above with $SIG{"ABRT"}.
[...] As it is I don't see any
evidence of them treating keys differently depending on the actual value
of the key, only evidence that some key/value pairs have been assigned
prior to the object being exposed. And as a result these are not exempts
of associative arrays that would treat keys of the same type differently
depending on the value of those keys.
I would logically say that those associative arrays treat certain keys
differently simply because they are pre-defined.
But can the programmer assign to the system defined keys (without
modification of the value or side effects)?
He can overwrite the keys in question, only in his own program/scope,
but that's not recommended for obvious reasons.

#!/usr/bin/perl
use strict;
use warnings;
print $ENV{"SYSTEMROOT"} . "\n";
$ENV{"SYSTEMROOT"} = "somethingelse";
print $ENV{"SYSTEMROOT"};

says:

C:\WINDOWS
somethingelse
Does this mean that there are no associative arrays in
Perl ? Not at all.

I have not seen that these objects are unambiguously associative arrays,
though the code you posted does not contradict that, but even if they
were not that could not be extended to saying that Perl had no
associative arrays. But javascript only has one object type, either that
object is an associative array or javascript has no associative arrays,
it is that black and white.
It means that a Perl programmer must be aware of how
associative arrays work in Perl,

Surely it means that Pearl programmers have to be aware that these
particular associative arrays are partly pre-populated with significant
keys?
That is correct. And the general rule is to not modify them unless you
have a (very) good reason. I haven't seen any such case where that
would be desired though.
Yes, does it have any implications for when they create a new hash from
scratch?
Well, the hashes in question are pre-existing and have a number of
pre-defined keys. You might reset the hash or do what you like with it.
But you should really try to avoid that, the purpose for their
existence is to read them out for whatever reason.

#!/usr/bin/perl
use strict;
use warnings;
while (my ($key, $value) = each %ENV) {
print "$key = $value \n";
}

prints (for me):

USERPROFILE = C:\Documents and Settings\DOT
HOMEDRIVE = C:
TEMP = C:\DOCUME~1\DOT\LOCALS~1\Temp
SYSTEMDRIVE = C:
PROCESSOR_REVISION = 0304
SYSTEMROOT = C:\WINDOWS
CLIENTNAME = Console
COMMONPROGRAMFILES = C:\Program Files\Common Files
COMSPEC = C:\WINDOWS\system32\cmd.exe
SESSIONNAME = Console
LOGONSERVER = \\BART
APPDATA = C:\Documents and Settings\DOT\Application Data
WINDIR = C:\WINDOWS
PROGRAMFILES = C:\Program Files
OS = Windows_NT
PROCESSOR_LEVEL = 15
PATHEXT = .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH
USERNAME = DOT
PROMPT = $P$G
NUMBER_OF_PROCESSORS = 1
FP_NO_HOST_CHECK = NO
HOMEPATH = \Documents and Settings\DOT
PROCESSOR_IDENTIFIER = x86 Family 15 Model 3 Stepping 4, GenuineIntel
PATH = c:\Perl\bin;C:\WINDOWS\system32;C:\WINDOWS
USERDOMAIN = BART
COMPUTERNAME = BART
ALLUSERSPROFILE = C:\Documents and Settings\All Users
PROCESSOR_ARCHITECTURE = x86
CLASSPATH = .;
TMP = C:\DOCUME~1\DOT\LOCALS~1\Temp

I can change every key and/or value, but that only effects %ENV as a
variable and not the 'real' environmental information that I got at the
start. Next time, or even next scope, %ENV will have the same
prepopulated key/values again. It differs from javascript where one
cannot change such predefined values. Instructions like, say,
navigator.appName = '1234' are not accepted in javascript.
Also, Perl hashes know other particularities: no sorting
possibilities, multi-dimensional hashes, (de)referencing
to other vars in hash values,

None of which help the decision either way.
additional forbidden keys from modules, etc.

But that may be very significant. Can you say more? Or does this only
apply to the special pre-populated hashes you started with?
No, it applies to all variables - it's a simple mechanism. Perl modules
might behave the same as an external .js file in this regard. Variables
originating from external code can be exported to the main programme.

--
Bart

Nov 30 '06 #31

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Gary | last post: by
7 posts views Thread by =?Utf-8?B?YXVsZGg=?= | last post: by
1 post views Thread by gcdp | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.