Re: Hash arrays [was: does property exists in a record]
Re: Hash arrays [was: does property exists in a record]
- Subject: Re: Hash arrays [was: does property exists in a record]
- From: John W Baxter <email@hidden>
- Date: Tue, 14 Aug 2001 22:29:20 -0700
At 11:27 -0700 8/14/2001, Stockly, Ed wrote:
[Quoting someone]
>
>>From what I can see, the clamor for them (associative arrays)
>
>>here seems to be limited to a relatively small number of players.
>
>>Maybe the rest are just silently nodding, but I suspect not.
>
Well, I guess I'm nodding. But not because I want to write some highly
>
complex scripting algorithms.
If one has used a language in which a very common pattern is to use an
associative array, one misses the ability sorely in AppleScript. Such
languages include Perl, Python, Smalltalk (although it has other patterns
that absorb some of the Perl/Python uses), modern C++, and many others. I
expect to count words in a file by building an associative array with the
words as keys, and incrementing the values for each word encountered.
AppleScript users, not having that ability in the language, have other
expectations and use other tools.
>
My feeling is that if lists and records acted like proper AppleScript
>
objects and could be addressed by whose clauses and could be easily
>
manipulated (deleting items, sorting by various keys) and, in the case of
>
records, if labels could easily be coerced to and from text strings, then
>
they would be far more useful to the average scripter. If that is a
>
benefit of changing them to associative arrays then I think it's important
>
and I'm all for it. If not, then I'll stop nodding.
A frustrating thing about the record labels is that they are sitting in
memory as strings (letter case differences ignored), except for the labels
which happen to match terminology (where the letter case rules differ from
those of the other labels).
If we could do this:
set a to {application:"a", bravo:"b", charlie:"c", mnemonic:"m"}
set b to <<class usrf>> of a --unfortunately fails in the real world
a
and if terminology matches were ignored when records were built, then we
could retrieve the labels (keys) and values of the record and deal with
them rather easily (see below)
Here are the strings, and the annoying "application" label found in a from
the above...just sitting there tantalizing us (from Script Debugger's
result window set to "aeprint" format):
{
capp:"a",
usrf:[
"bravo",
"b",
"charlie",
"c",
"mnemonic",
"m"
]
}
Failing handler to get the labels:
-- get the labels from a record
on getLabels(aRecord) --doesn't work because first command fails
set theFields to <<class usrf>> of aRecord
set theLabels to {}
repeat with ix from 1 to length of theFields step 2
set end of theLabels to item ix of theFields
return theLabels
end getLabels
I can write a Frontier script such that the failing line in the handler
above could be replaced by a call of the Frontier script (but the items
whose labels match terminology are still a problem). And a Scripting
Addition could easily do the job...perhaps one already does.
Chris N...would there be support within Apple for doing away with the
special handling of record labels like application (just as one example),
putting all items in the 'usrf' list; and providing syntax for retrieving
the 'usrf' list, as pseudo-coded above? The first half (removing the
special casing) would probably be harder than the second, since I suspect
in the real implementation, not treating the terminology-matching labels as
they are now would be a special case in the parser (ah...let the parser do
its thing and let the record builder decompile the codes back to
terminology, perhaps).
The script writer, having properly adjusting the styling of the "parts of
speech" in AppleScript, can tell whether there are any non-usrf items in a
record visible in script editor and pick different labels, if it comes to
that...or make use of pipes:
set a to {|application|:"a", |Bravo|:"b", charlie:"c", mnemonic:"m"}
which in the bargain will do away with the often-unwanted case smashing
which goes on in labels:
{
usrf:[
"application",
"a",
"Bravo",
"b",
"charlie",
"c",
"mnemonic",
"m"
]
}
--john
--
John Baxter Port Ludlow, WA, USA
I am NOT out of the office. I will respond if and when I get around to it.