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

[Abdullah Kauchali]

Hi folks,

Can one rely on the order of keys inserted into an associative Javascript
array? For example:
var o = new Object();

o["first"] = "Adam";
o["second"] = "Eve";
o["third"] = "Cane";
o["fourth"] = "Abel";

..
..
..

//then

for (var i in o){
alert(i);
}

Is the order in this "for loop" *guaranteed* to be:
first, second, third, fourth?

Also, if the "third" key is deleted, is the order still guaranteed?

I've tested this in IE and Firefox, and it seems to work. I'd be grateful
for any links that indicate this in Javascript standards/specs.

Many thanks & kind regards,

Abdullah

[ZER0]

On Tue, 25 May 2004 12:35:50 +0200, Abdullah Kauchali wrote:

[cut]

Is the order in this "for loop" *guaranteed* to be:
first, second, third, fourth?
Unfortunately, not.
Depend of the browser's implementation of this aspect of ECMAScript
specifications.

In IE,old Netscape versions, and Gecko based browsers, the order is
"chronological".. But.. try with Opera.
for any links that indicate this in Javascript standards/specs.

http://www.ecma-international.org/pu...T/Ecma-262.pdf

[for-in statement]
"The mechanics of enumerating the properties (..) is
implementation dependent. The order of enumeration is defined by the
object. (..) "

--
ZER0://coder.gfxer.web-designer/

~ Come devo regolare la stampante laser per stordire?
(How do I set a laser printer to stun?)

on air ~ "Linkin Park - Somewhere I Belong (real song)"

[Abdullah Kauchali]

"ZER0" <ze********@libero.it> wrote in message

http://www.ecma-international.org/pu...T/Ecma-262.pdf

[for-in statement]
"The mechanics of enumerating the properties (..) is
implementation dependent. The order of enumeration is defined by the
object. (..) "

Ho bummer! :(

Thanks for that Zero.

Now, how do I accomplish the following if the order is not guaranteed:

1. Put objects within the "collection";
2. Access each one according to the order in which they were put into the
collection.

So far, I have this:

It seems to me that the most straight-forward answer would be to create
another "collection" with index numbers beginning with 0 and then always
incrementing for additions to the collections. Once a index/offset number
is used, it cannot be reused.

So, after some additions and deletions, I'll get something like:

1, 2, 3, 7, 9, 11, 23

if I wanted to add to this collection, the next one would be 24 and so on.

Is that the most elegant solution?

Kind regards

Abdullah

[Douglas Crockford]

> Can one rely on the order of keys inserted into an associative Javascript

array? For example:

var o = new Object();

o["first"] = "Adam";
o["second"] = "Eve";
o["third"] = "Cane";
o["fourth"] = "Abel";

No. The ECMAScript specification allows the contents of an object to be
unordered. Most implementations do order the contents, but you should
not rely on that.

Also, the preferred way of initializing an object is with the object
literal notation.

var o = {first: "Adam", second: "Eve", third: "Cain",
fourth: "Abel"};

See http://www.JSON.org

[Abdullah Kauchali]

"ZER0" <ze********@libero.it> wrote in message

"chronological".. But.. try with Opera.

Just tried it with Opera 7.50 and it seems to honour the order in which it
was originally put in - the same as IE and Mozilla/FF.

Almost there, but no official sanction from the specs! :(

[ZER0]

On Tue, 25 May 2004 15:43:45 +0200, Abdullah Kauchali wrote:

Just tried it with Opera 7.50 and it seems to honour the order in which it
was originally put in - the same as IE and Mozilla/FF.
The last Opera I've seen was 7.0; and in that version the order was
different.

So, Now Opera seems use the same order of IE and Gecko.. Good news.
Almost there, but no official sanction from the specs! :(

Yes, as I said is implementation dependent.

--
ZER0://coder.gfxer.web-designer/

~ Tutti quelli che credono nella psicocinesi, per favore alzino la mia
mano.

on air ~ "Avril Lavigne - Don't Tell Me"

[Abdullah Kauchali]

"Douglas Crockford" wrote in message

var o = {first: "Adam", second: "Eve", third: "Cain",
fourth: "Abel"};

I don't think I can do that. The key/value pairs are unknown until runtime.

Unless, of course, I am unaware of the way to initialise the way you mention
for key/value pairs only known at runtime, then I'd be glad to learn how to
do it.

Kind regards

Abdullah

[Grant Wagner]

Abdullah Kauchali wrote:

"ZER0" <ze********@libero.it> wrote in message

http://www.ecma-international.org/pu...T/Ecma-262.pdf

[for-in statement]
"The mechanics of enumerating the properties (..) is
implementation dependent. The order of enumeration is defined by the
object. (..) "

Ho bummer! :(

Thanks for that Zero.

Now, how do I accomplish the following if the order is not guaranteed:

1. Put objects within the "collection";
2. Access each one according to the order in which they were put into the
collection.

So far, I have this:

It seems to me that the most straight-forward answer would be to create
another "collection" with index numbers beginning with 0 and then always
incrementing for additions to the collections. Once a index/offset number
is used, it cannot be reused.

So, after some additions and deletions, I'll get something like:

1, 2, 3, 7, 9, 11, 23

if I wanted to add to this collection, the next one would be 24 and so on.

Is that the most elegant solution?

Kind regards

Abdullah

That's pretty much what you do. You can wrap it in functions to make it easier
to manage:

function addToCollection(collection, collectionOrder, property, value) {
collection[property] = value;
collectionOrder.push(property);
}

function removeFromCollection(collection, collectionOrder, property) {
collection[property] = null;
for (var i = 0; i < collectionOrder.length; i++) {
if (collectionOrder[i] == property) {
collectionOrder[i] = null;
break;
}
}
}

function dumpCollection(collection, collectionOrder) {
var output = [];
for (var i = 0; i < collectionOrder.length; i++) {
if (collectionOrder[i] != null) {
output.push(collection[collectionOrder[i]]);
}
}
return output;
}

var o = new Object();
var oOrder = new Array();

addToCollection(o, oOrder, "first", "Adam");
addToCollection(o, oOrder, "second", "Eve");
addToCollection(o, oOrder, "third", "Cane");
addToCollection(o, oOrder, "fourth", "Abel");
removeFromCollection(o, oOrder, "second");
addToCollection(o, oOrder, "fifth", "Noah");
alert(dumpCollection(o, oOrder));

If you want to get really fancy, you could write a "Collection" object that
encapsulates all this functionality:

function Collection() {
var collection = {};
var order = [];

this.add = function(property, value) {
if (!this.exists(property)) {
collection[property] = value;
order.push(property);
}
}
this.remove = function(property) {
collection[property] = null;
for (var i = 0; i < order.length; i++) {
if (order[i] == property) {
order[i] = null;
break;
}
}
}
this.toString = function() {
var output = [];
for (var i = 0; i < order.length; i++) {
if (order[i] != null) {
output.push(collection[order[i]]);
}
}
return output;
}
this.getKeys = function() {
var keys = [];
for (var i = 0; i < order.length; i++) {
if (order[i] != null) {
keys.push(order[i]);
}
}
return keys;
}
this.update = function(property, value) {
if (value != null) {
collection[property] = value;
}
for (var i = 0; i < order.length; i++) {
if (order[i] == property) {
order[i] = null;
order.push(property);
break;
}
}
}
this.exists = function(property) {
return collection[property] != null;
}
}

var myCollection = new Collection();
myCollection.add("first", "Adam");
myCollection.add("second", "Eve");
myCollection.add("third", "Cane");
myCollection.add("fourth", "Abel");
myCollection.remove("second");
myCollection.add("fifth", "Noah");
alert(myCollection.toString());
alert(myCollection.getKeys());
myCollection.update("first");
alert(myCollection.toString());
alert(myCollection.exists("third"));
alert(myCollection.exists("something"));

The one thing you can't do with my code is actually store a null value in a
collection entry. If you need to be able to do that, then you should use
another object inside Collection to track if a collection entry actually
contains a value or not.

--
| Grant Wagner <gw*****@agricoreunited.com>

* Client-side Javascript and Netscape 4 DOM Reference available at:
*
http://devedge.netscape.com/library/...ce/frames.html

* Internet Explorer DOM Reference available at:
*
http://msdn.microsoft.com/workshop/a...ence_entry.asp

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

[Abdullah Kauchali]

"Grant Wagner" <gw*****@agricoreunited.com> wrote in message

<humbling code example snipped>

OMG. Thank you so much. Beats the hell out of making the attempts on my
own!

Many thanks, once again,

Kind regards

Abdullah

[ZER0]

On Tue, 25 May 2004 17:38:49 GMT, Grant Wagner wrote:

That's pretty much what you do. You can wrap it in functions to make it easier
to manage: [cut] If you want to get really fancy, you could write a "Collection" object that
encapsulates all this functionality:

An Additional note: This code on IE, works only for version 5.5 or major;
because it use the push() array's method.

--
ZER0://coder.gfxer.web-designer/

~ You don't have to be crazy to be a webmaster. But it helps.

[Grant Wagner]

ZER0 wrote:

On Tue, 25 May 2004 17:38:49 GMT, Grant Wagner wrote:

That's pretty much what you do. You can wrap it in functions to make it easier
to manage:

[cut]

If you want to get really fancy, you could write a "Collection" object that
encapsulates all this functionality:

An Additional note: This code on IE, works only for version 5.5 or major;
because it use the push() array's method.

--
ZER0://coder.gfxer.web-designer/

~ You don't have to be crazy to be a webmaster. But it helps.

if (typeof Array.prototype.push != 'function') {
Array.prototype.push = function() {
for (var i = 0 ; i < arguments.length ; i++) {
this[this.length] = arguments[i];
}
}
}

--
| Grant Wagner <gw*****@agricoreunited.com>

* Client-side Javascript and Netscape 4 DOM Reference available at:
*
http://devedge.netscape.com/library/...ce/frames.html

* Internet Explorer DOM Reference available at:
*
http://msdn.microsoft.com/workshop/a...ence_entry.asp
* Netscape 6/7 DOM Reference available at:
* http://www.mozilla.org/docs/dom/domref/
* Tips for upgrading JavaScript for Netscape 7 / Mozilla
* http://www.mozilla.org/docs/web-deve...upgrade_2.html

[ZER0]

On Wed, 26 May 2004 13:21:55 GMT, Grant Wagner wrote:

An Additional note: This code on IE, works only for version 5.5 or major;
because it use the push() array's method.

if (typeof Array.prototype.push != 'function') {

[cut]

Better. :)

--
ZER0://coder.gfxer.web-designer/

~ Plagiarism is copying from one source;
research is copying from two or more
(Wilson Mizner)

[Thomas 'PointedEars' Lahn]

Abdullah Kauchali wrote:

Can one rely on the order of keys inserted into an associative Javascript
array? For example:
JavaScript and other ECMAScript implementations have no built-in
concept of associative arrays.
var o = new Object();

o["first"] = "Adam";
o["second"] = "Eve";
o["third"] = "Cane";
o["fourth"] = "Abel";

That is an Object object on which alphabetic properties are added, not
an array. Try o.length or o.push(), neither is present or works, while
o.first, o.second aso. work. (If properties are identifiers, they can
be accessed both with the square bracket and the dot accessor.)

Using Mozilla/5.0 and a for-in-loop, properties are iterated in the
order of assignment, but there is no standard that specifies that.

Additional note: Even

var a = new Array();
a[0] = 42;
a["foo"] = "bar";

creates an array with *one* element, not two:

alert(a.length); // 1

var s = "";
for (var i in a)
{
s += i + " == " + a[i] + "\n";
}
alert(s);
PointedEars

[John G Harris]

In article <40**************@PointedEars.de>, Thomas 'PointedEars' Lahn
<Po*********@nurfuerspam.de> writes

Abdullah Kauchali wrote:

Can one rely on the order of keys inserted into an associative Javascript
array? For example:

JavaScript and other ECMAScript implementations have no built-in
concept of associative arrays.

<snip>

It's the other way round. Every ECMAScript object is an associative
array.

Even Array objects are associative arrays. It's a syntax fudge that
makes Array objects look, almost, like the arrays in other languages
with their numeric indexes.

John
--
John Harris

[Lasse Reichstein Nielsen]

John G Harris <jo**@nospam.demon.co.uk> writes:

It's the other way round. Every ECMAScript object is an associative
array.

.... where "associative array" is just mumbo-jumbo for a mapping from
something to something. I believe the name comes from Perl, although
they could have taken it from somewhere else. It is really a misnomer,
as it has nothing to do with "real" arrays.

In, e.g., Java, I would never say "associative array". I'd just say
"Map".

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[John G Harris]

In article <8y**********@hotpop.com>, Lasse Reichstein Nielsen
<lr*@hotpop.com> writes

John G Harris <jo**@nospam.demon.co.uk> writes:

It's the other way round. Every ECMAScript object is an associative
array.
... where "associative array" is just mumbo-jumbo for a mapping from
something to something. I believe the name comes from Perl, although
they could have taken it from somewhere else. It is really a misnomer,
as it has nothing to do with "real" arrays.

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

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

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

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

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

John
--
John Harris

[Thomas 'PointedEars' Lahn]

Lasse Reichstein Nielsen wrote:

John G Harris <jo**@nospam.demon.co.uk> writes:

It's the other way round. Every ECMAScript object is an associative
array.

... where "associative array" is just mumbo-jumbo for a mapping from
something to something. I believe the name comes from Perl, although
they could have taken it from somewhere else. It is really a misnomer,
as it has nothing to do with "real" arrays.

In, e.g., Java, I would never say "associative array". I'd just say
"Map".

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

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

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

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

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

or

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

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

Achieving that in ECMAScript and implementations requires another data
structure similar to Array objects, which I refer to as a "collection",
as specified for example with the HTMLCollection interface of the W3C
DOM.
PointedEars
___________
[1] Note the character case!

[Grant Wagner]

John G Harris wrote:

In article <40**************@PointedEars.de>, Thomas 'PointedEars' Lahn
<Po*********@nurfuerspam.de> writes

Abdullah Kauchali wrote:

Can one rely on the order of keys inserted into an associative Javascript
array? For example:
JavaScript and other ECMAScript implementations have no built-in
concept of associative arrays.

<snip>

It's the other way round. Every ECMAScript object is an associative
array.

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

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

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

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

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

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

and

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

to have the same outcome.

--
| Grant Wagner <gw*****@agricoreunited.com>

* Client-side Javascript and Netscape 4 DOM Reference available at:
*
http://devedge.netscape.com/library/...ce/frames.html

* Internet Explorer DOM Reference available at:
*
http://msdn.microsoft.com/workshop/a...ence_entry.asp

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

[Lasse Reichstein Nielsen]

Grant Wagner <gw*****@agricoreunited.com> writes:

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

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

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

</nitpick>
/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[rh]

Grant Wagner wrote:

John G Harris wrote:
<snip>

It's the other way round. Every ECMAScript object is an associative
array.

No, every ECMAScript object is an object that can have properties which can be
accessed using dot notation (theObject.theProperty), or "array" notation
(theObject[theProperty]).

The original statement is correct. The accessor syntax, while being
important, doesn't change the fundamental (logical) nature of the
object.

Even Array objects are associative arrays. It's a syntax fudge that
makes Array objects look, almost, like the arrays in other languages
with their numeric indexes.

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

Again, the original statement is correct.

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

<snip>
By the way, Location is "magical" because it behaves in a way that is impossible
if it were a normal object.

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

../rh

[Thomas 'PointedEars' Lahn]

rh wrote:

Grant Wagner wrote:

John G Harris wrote:

> It's the other way round. Every ECMAScript object is an associative
> array.

No, every ECMAScript object is an object that can have properties which can be
accessed using dot notation (theObject.theProperty), or "array" notation
(theObject[theProperty]).

The original statement is correct. The accessor syntax, while being
important, doesn't change the fundamental (logical) nature of the
object.

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

[Lee]

Thomas 'PointedEars' Lahn said:

Lasse Reichstein Nielsen wrote:

John G Harris <jo**@nospam.demon.co.uk> writes:

It's the other way round. Every ECMAScript object is an associative
array.
... where "associative array" is just mumbo-jumbo for a mapping from
something to something. I believe the name comes from Perl, although
they could have taken it from somewhere else. It is really a misnomer,
as it has nothing to do with "real" arrays.

In, e.g., Java, I would never say "associative array". I'd just say
"Map".

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

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

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

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

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

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

[rh]

Thomas 'PointedEars' Lahn <Po*********@nurfuerspam.de> wrote in message news:<40**************@PointedEars.de>...

rh wrote:

Grant Wagner wrote:

John G Harris wrote:
> It's the other way round. Every ECMAScript object is an associative
> array.

No, every ECMAScript object is an object that can have properties which can be
accessed using dot notation (theObject.theProperty), or "array" notation
(theObject[theProperty]).

The original statement is correct. The accessor syntax, while being
important, doesn't change the fundamental (logical) nature of the
object.

The fundamental (logical) nature of any object is not to be an "associative
array" (whatever that might be) but to be an object having properties and
methods, encapsulating data.

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

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

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

../rh

[rh]

Lee wrote:

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

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

../rh

[Thomas 'PointedEars' Lahn]

rh wrote:

Thomas 'PointedEars' Lahn [...] wrote [...]...

rh wrote:
Only because ECMAScript is a loosely typed
language where properties can be added and removed during runtime and those
of type "function" are considered methods of the object, does not make an
object per se an array.

No, but it does mean that an objects ECMAScript are conceptually based
on associative arrays.

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

[rh]

Thomas 'PointedEars' Lahn wrote:

rh wrote:

Thomas 'PointedEars' Lahn [...] wrote [...]...

rh wrote:
Only because ECMAScript is a loosely typed
language where properties can be added and removed during runtime and those
of type "function" are considered methods of the object, does not make an
object per se an array.

No, but it does mean that an objects ECMAScript are conceptually based
on associative arrays.

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

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

../rh

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

[Marek Mänd]

Douglas Crockford wrote:

Can one rely on the order of keys inserted into an associative Javascript
array? For example:

var o = new Object();

o["first"] = "Adam";
o["second"] = "Eve";
o["third"] = "Cane";
o["fourth"] = "Abel";

No. The ECMAScript specification allows the contents of an object to be
unordered. Most implementations do order the contents, but you should
not rely on that.

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

--
marekmand

[Grant Wagner]

Marek Mänd wrote:

Douglas Crockford wrote:

Can one rely on the order of keys inserted into an associative Javascript
array? For example:

var o = new Object();

o["first"] = "Adam";
o["second"] = "Eve";
o["third"] = "Cane";
o["fourth"] = "Abel";

No. The ECMAScript specification allows the contents of an object to be
unordered. Most implementations do order the contents, but you should
not rely on that.

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

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

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

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

--
Grant Wagner <gw*****@agricoreunited.com>
comp.lang.javascript FAQ - http://jibbering.com/faq