Not so sure (was Re: Scott Norton is brilliant (was: solutions to scripting addition t erminology confilicts))
Not so sure (was Re: Scott Norton is brilliant (was: solutions to scripting addition t erminology confilicts))
- Subject: Not so sure (was Re: Scott Norton is brilliant (was: solutions to scripting addition t erminology confilicts))
- From: email@hidden (Michael Sullivan)
- Date: Fri, 25 Jan 2002 17:23:38 -0500
- Organization: Society for the Incurably Pompous
Olaf Hellman writes:
>
5c) AppleScript will still load the AppleEvent handlers defined in the
>
'osax' or 'osiz' resources into the system dispatch table. Thus, the events
>
still get handled by the OSAX with all the inherent speed advantages.
Except...
Do osaxen have any speed advantages over apps?
It strikes me that they don't -- they still involve an apple event call,
it's just to the system instead of an app. Maybe that makes it
marginally faster, but it still takes aeons compared to a straight
language command.
My feeling is that I'd like to be able to attach osax (or similar) code
directly to a compiled script so that the script can call it without any
apple event overhead. Right now additions (whether osaxen or FBAs) are
only useful if they can provide a fairly complete solution to a large
portion of a problem. Short little hacks that could prove enormously
useful if they could be run at speed, become of limited help because of
the apple event overhead if they must be looped through many times.
ASCII number/character is a perfect example. If it could be executed at
the speed of a typical set command on a number or short string, it would
eliminate the need for hacks such as Arthur's that make use of the
record as list as string feature^H^H^H^H^H^H^Hbug.
The osax as it exists is fine for very scripts, but utterly useless for
heavy text manipulation. All because of the apple event overhead in
calling an osax.
Michael
--
Michael Sullivan
Business Card Express of CT Thermographers to the Trade
Cheshire, CT email@hidden