Re: interesting discovery (trying to get record labels as strings)
Re: interesting discovery (trying to get record labels as strings)
- Subject: Re: interesting discovery (trying to get record labels as strings)
- From: has <email@hidden>
- Date: Tue, 4 Dec 2001 00:39:17 +0000
Jeff Baumann cried:
>
OK, I can't handle this anymore! usrf! Raw contents of Apple Event Manager
>
records! AssociativeLib script objects! Aaarrgghh!!!! I'm too concrete for
>
such things. I like text. Text will still be around in 50 years. None of the
>
other stuff will be.
It's like Invasion Of The Body Snatchers, dude. You'll wake up one morning
and find everything around you has turned into Objects. ;)
I think what suits you best depends a lot on your needs. Messing with
records is useful for what I'm doing, but for other tasks a different
pseudo-hash scheme may be preferable.
I wrote hashLib so I could 1. easily store any type of object (everything
from booleans to script objects, not just strings), and 2. access the same
data either by traditional references (very fast) or by using objects as
keys (can be generated on-the-fly), depending on circumstance. The tradeoff
is that it's tied to Smile, but that's ok for me because Smile is being
used as the base to the overall project anyway. Most of the time I'll use
it to generate a nice big record on-the-fly, then look up stuff in the
records using straight references - it should be spanking for that. None of
this stored content is intended for long-term storage either - it's just
there as a means to an end.
Though I'll also be looking for a good database mechanism later on, so who
knows... I may even end up using yours.;)
>
The *real* fix to the need for an efficient data structure *must* come from
>
Apple. Anything else will be slow and clunky.
True. Although... perhaps now we're seeing some signs of a strong pent-up
demand, the AppleScript team will find it in their hearts to bump it up
their priority list a few notches? Hey, we can but hope...;)
------
>
Here is how I solved the "lack of hash tables" dilemma. I started with the
>
format of the posted_data which a CGI receives from a form post (a=1&b=2&c=3,
>
URL encoded). I then built several handlers to let me use that structure to
>
emulate hash tables. The system has proven to be very reliable, very fast,
>
and very flexible.
It sounds pretty darn impressive, and a fascinating approach. I'm going to
sit down and play with it later... figure it out.
>
My big (huge, overwhelming) concern is that there is currently no way to
>
implement this in OSX, since it depends on Tanaka's osax (a MacOS classic
>
scripting addition). I think I saw a post about how to access classic osaxen
>
from OSX scripts. Can someone verify that/provide syntax?
I remember that one too. IIRC, you create a stay-open applet that runs in
Classic, with the osax's functions in handlers:
on MTEncodeURL(theString)
MT Encode URL theString
end MTEncodeURL
>
Even still, the
>
functionality of Tanaka's osax really needs to be provided natively in OSX.
I suspect the AS team already have plenty on their plates.:) It may remain
a 3rd-party opportunity for some time to come. If you were desperate, maybe
wafting cash sums at osaxen authors to encourage them to upgrade their code
would help?
>
Even an encode/decode URL function would prove very helpful.
I've a library implementation that does html/url encoding/decoding that's
mostly done. But if you need speed, forget it: an osax will be 10-100 times
faster, easy.
Also, have you looked at Arthur's tid-based pseudo-hash script? (I reposted
a copy here the other day.) It also stores stuff as text - inside an
object, admittedly, but it's no biggie if you want to get the sData string
out as-is/write it to file/etc.
------
>
on LRlookupFieldValue(desiredField, listOfPairedLists)
[snip]
>
end LRlookupFieldValue
You'll need to insert an "on error" line before "end try" in the above
handler to get it working on OS8.x. (Not sure why "on error" became
optional in OS9; all it would seem to do is make scripts authored in 9+
more likely to break in 8.x...:/)
------
Cheers,
has