Re: Not so sure (was Re: Scott Norton is brilliant (was:
Re: Not so sure (was Re: Scott Norton is brilliant (was:
- Subject: Re: Not so sure (was Re: Scott Norton is brilliant (was:
- From: Arthur J Knapp <email@hidden>
- Date: Sat, 26 Jan 2002 13:01:48 -0500
>
Date: Sat, 26 Jan 2002 01:28:49 +0000
>
From: has <email@hidden>
>
Subject: Re: Not so sure (was Re: Scott Norton is brilliant (was:
>
> 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.
>
>
Personally, I wouldn't use Arthur's hack (sorry Arthur;)
No problem... ;-)
>
... simply because
>
it's impossible to guarantee that it will work on all machines now and in
>
the future (it seems tough enough vouching for standard code these
>
days...). But even a non-hack method will outstrip these osax calls several
>
times over, so replacing these calls with native code is an advantage in
>
speed-critical routines. Where they score is in convenience (one line
>
versus many), which is the main point of having them, I suppose.
I like the fact that this discussion is centering on long-term
solutions to the issues surrounding OSAXen, but how about some short
term ones:
Many of the speed problems involved with OSAXen calls would become
negligable simply by providing for lists of values to operate on,
instead of single values. To use character-set conversions, for
example, the reason it is so frustrating is because a seperate apple
event has to be sent for each "byte sized" character or integer that
the user is converting. How much more complicated would it be for
the ASCII number command to take a string and return a list of
integers, or for ASCII character to take a list of small integers and
return a string? Would it be too complicated for the offset command to
have a "returning every offset" parameter; for the random number
command to have a "returning x amount of random numbers" parameter?
Most speed issues involving scripting additions only come into
play when they are called repeatedly. If I were a programmer of
scripting additions, my primary concern would be to find ways
of ensuring that the commands were doing as much work as was
likely to be needed by the user.
(As a seperate issue: When I think about a command like "offset",
I can't help but wonder what thought process was used in it's
creation. No "ignore/consider case" parameter, no "last offset of"
commmand or parameter, it's as though some of these "Standard"
commands were thrown together with little or no thought at all.
Even if they were cobbled together quickly for a quick release of
AppleScript, they have barely undergone any changes at all since AS
was first released.)
>
... I suspect the biggest 'overhead' is simply that which comes
>
from using an interpreted - as opposed to compiled - language in the first
>
place. C'est la vie.
As a JavaScript user, I'm afraid I cannot agree, (or is JavaScript
the exception that proves the rule?). :)
>
Oh, and I nominate Scott for the "scariest AppleScripter of the year"
>
award. Yike!
It's a young year, but I suspect that you, (has), will be in
contention for this same award...
;-)
{ Arthur J. Knapp, of <
http://www.STELLARViSIONs.com>
<
mailto:email@hidden>
try
<
http://www.seanet.com/~jonpugh/>
on error number -128
end try
}