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

[Richard Cornford]

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
"associativ e 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 "associativ e 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
"associativ e 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
"associativ e array".

Richard.

[Richard Cornford]

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.refle ct - 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 "associativ e 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 "associativ e 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.

[Randy Webb]

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.javas cript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Richard Cornford]

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

[Randy Webb]

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:

>>Specificall y; 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.javas cript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Matt Kruse]

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.refle ct - 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

[Matt Kruse]

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 "unambiguou sly" 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

[Bart Van der Donck]

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{"SYSTEMROO T"} . "\n";

$INC{"aSecondKe y"} = "aSecondVal ue";
print "(3) " . $INC{"aSecondKe y"} . "\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

[John G Harris]

In article <ek************ *******@news.de mon.co.uk>, Richard Cornford
<Ri*****@litote s.demon.co.ukwr ites

<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

[Richard Cornford]

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{"SYSTEMROO T"} . "\n";

$INC{"aSecondKe y"} = "aSecondVal ue";
print "(3) " . $INC{"aSecondKe y"} . "\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.