Richard said:
Bart said:
Richard said:
[...] 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
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.
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.
None of which help the decision either way.
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.
