Yeah, well, I didn't exactly forget it. Using run script as a form
of second-level evaluation is in the book, all right, but I also
point out that it's really a pretty crappy thing to do, so I
advise against it. There are times when one just *has* to use it,
of course. But in this case the record-and-osax solution is way
cleaner (esp now that we have portable osax distribution). m.
Yes, I think so, too. The complete answer is: yes, it could be
done, it's a tricky way, this language wasn't designed to support
such thing, so use the built-in methods and don't think this is
javascript nor a similar thing.
I disagree with the use of a script. Being able to contain zero or
more objects like itself (or pointers thereto) is a basic feature of
object oriented design. The «script» object is the fundamental object
OSA object and all scripts are stored at peer level in OSA components
in a Handle. Therefore, a call to an embedded script is inherently
faster than a call like "tell application "XXX" to ..." because there
is no message passing -- only a direct call in the component to
another script.
The difference in time between getting a property value directly from
a compiled script and getting its value via a 'run script' compiled
in another script would be roughly the difference in time between
(say) 2 and 4 pointer dereferences plus the time needed to assemble
the text of the script if it is done dynamically. A very tiny amount
of time. In that respect the posted script could probably be sped up
marginally by assembling the command outside of the run script call.
The difference in time between getting a property value directly from
a compiled script and getting some keyed value from a facility in an
OSAX will mostly depend on the manner which the OSAX is managing the
data.
