array.["property"]
|
|
Thread rating:  |
josh - 21 Nov 2006 14:09 GMT Hi all, what does it meaning that strange sintax (look at the object :) ?
if I have i.e. array.length I can use array.["length"] and is it IE/Firefox compatible??
Lee - 21 Nov 2006 14:24 GMT josh said:
>Hi all, >what does it meaning that strange sintax (look at the object :) ? You seem to mean "look at the subject", and that's a nuisance with some newsreaders. Don't ask people to read the subject while they're reading the message.
>if I have i.e. array.length I can use array.["length"] and is it >IE/Firefox compatible?? No, you can't use that syntax in any browser, but you should be able to use: array["length"] in any. There's no "dot".
You can use this notation to access attributes of any Object.
--
adamraney@gmail.com - 21 Nov 2006 14:26 GMT Try it without the dot:
array['length'] is equivilant to array.length.
> 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?? Martijn Saly - 21 Nov 2006 14:29 GMT > 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.
 Signature Martijn Saly
josh - 21 Nov 2006 14:59 GMT Martijn Saly ha scritto:
> In javascript, an object is the same as an associative array, which > makes the formal difference between arrays and objects blurry. please explain better what it mean 'makes the formal difference between arrays and objects blurry'
Martijn Saly - 21 Nov 2006 15:21 GMT > Martijn Saly ha scritto: > [quoted text clipped - 3 lines] > 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.
 Signature Martijn Saly
Randy Webb - 21 Nov 2006 19:52 GMT Martijn Saly said the following on 11/21/2006 10:21 AM:
>> Martijn Saly ha scritto: >> [quoted text clipped - 28 lines] > > 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.
 Signature Randy Chance Favors The Prepared Mind comp.lang.javascript FAQ - http://jibbering.com/faq Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
RobG - 21 Nov 2006 21:01 GMT > Martijn Saly ha scritto: > [quoted text clipped - 3 lines] > 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.
 Signature Rob
Randy Webb - 21 Nov 2006 19:49 GMT Martijn Saly said the following on 11/21/2006 9:29 AM:
>> Hi all, >> what does it meaning that strange sintax (look at the object :) ? [quoted text clipped - 6 lines] > 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.
 Signature Randy Chance Favors The Prepared Mind comp.lang.javascript FAQ - http://jibbering.com/faq Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Matt Kruse - 21 Nov 2006 20:42 GMT > 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>
 Signature Matt Kruse http://www.JavascriptToolbox.com http://www.AjaxToolbox.com
Richard Cornford - 22 Nov 2006 01:49 GMT >> 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: > [quoted text clipped - 8 lines] > 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.
John G Harris - 22 Nov 2006 21:30 GMT <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
 Signature John Harris
Richard Cornford - 26 Nov 2006 04:44 GMT > 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.
Matt Kruse - 27 Nov 2006 01:58 GMT > 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.
 Signature Matt Kruse http://www.JavascriptToolbox.com http://www.AjaxToolbox.com
Richard Cornford - 27 Nov 2006 23:36 GMT >> Being general is what an >> associative array is expected to do. Otherwise where would [quoted text clipped - 5 lines] > 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.
Matt Kruse - 28 Nov 2006 04:32 GMT >> 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.
 Signature Matt Kruse http://www.JavascriptToolbox.com http://www.AjaxToolbox.com
Bart Van der Donck - 27 Nov 2006 10:33 GMT > 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.
 Signature Bart
Richard Cornford - 27 Nov 2006 23:36 GMT >> But what you are calling pollution here is precisely what >> makes it inappropriate to speak of the result as an associative [quoted text clipped - 6 lines] > "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 [quoted text clipped - 4 lines] > 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.
Randy Webb - 27 Nov 2006 23:44 GMT 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?
 Signature Randy Chance Favors The Prepared Mind comp.lang.javascript FAQ - http://jibbering.com/faq Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Richard Cornford - 28 Nov 2006 01:21 GMT > Richard Cornford said the following on 11/27/2006 6:36 PM: >> Specifically; it no longer has the quality that all possible [quoted text clipped - 3 lines] > 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 - 28 Nov 2006 02:20 GMT Richard Cornford said the following on 11/27/2006 8:21 PM:
>> Richard Cornford said the following on 11/27/2006 6:36 PM: >>> Specifically; it no longer has the quality that all possible [quoted text clipped - 4 lines] > > 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.
 Signature Randy Chance Favors The Prepared Mind comp.lang.javascript FAQ - http://jibbering.com/faq Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Matt Kruse - 28 Nov 2006 04:41 GMT >> 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. ;)
 Signature Matt Kruse http://www.JavascriptToolbox.com http://www.AjaxToolbox.com
Bart Van der Donck - 28 Nov 2006 10:51 GMT > [...] 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.
 Signature Bart
Richard Cornford - 30 Nov 2006 01:01 GMT >> [...] Can you cite an example of something that unambiguously >> is an associative array that would treat keys of the same type [quoted text clipped - 20 lines] > (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.
Bart Van der Donck - 30 Nov 2006 10:45 GMT > >> [...] Can you cite an example of something that unambiguously > >> is an associative array that would treat keys of the same type [quoted text clipped - 35 lines] > 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. [quoted text clipped - 12 lines] > 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 [quoted text clipped - 6 lines] > 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.
 Signature Bart
John G Harris - 28 Nov 2006 21:24 GMT <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 [quoted text clipped - 3 lines] >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
 Signature John Harris
Randy Webb - 22 Nov 2006 02:07 GMT Matt Kruse said the following on 11/21/2006 3:42 PM:
>> 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.
 Signature Randy Chance Favors The Prepared Mind comp.lang.javascript FAQ - http://jibbering.com/faq Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Matt Kruse - 22 Nov 2006 03:30 GMT > 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.
 Signature Matt Kruse http://www.JavascriptToolbox.com http://www.AjaxToolbox.com
Bart Van der Donck - 27 Nov 2006 10:02 GMT > 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 [quoted text clipped - 6 lines] > 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.
 Signature Bart
RobG - 22 Nov 2006 02:41 GMT [...]
> 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: [quoted text clipped - 5 lines] > 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.
 Signature Rob
John G Harris - 22 Nov 2006 21:05 GMT <snip>
>Using a Javascript Object() as an Associative Array comes with the following >limitations: [quoted text clipped - 3 lines] > 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
 Signature John Harris
|
|
|