Re: How to simulate C's function pointer in AppleScript?
Re: How to simulate C's function pointer in AppleScript?
- Subject: Re: How to simulate C's function pointer in AppleScript?
- From: has <email@hidden>
- Date: Fri, 24 Oct 2008 20:18:06 +0100
Andre Berg wrote:
If I may ask, is there any grounds to my observation earlier, that
passing an escaped string containing
AppleScript commands to "run script" takes significantly longer for
processing them than passing those
same AppleScript commands wrapped in a script object?
May well do, but couldn't say for sure without testing as the
arguments and/or results you're passing could also make a significant
difference. The thing about 'run script' is that it's a scripting
addition command, which means that all of its arguments and results
must be transported via Apple events - i.e. serialised, packed into an
Apple event, passed to an Apple event handler, unpacked and de-
serialised; effectively pass-by-copy.
If you pass in a string, 'run script' will create a new AppleScript
interpreter instance, compile the string, and execute it. If you pass
in a script object, the script object will be copied and run. The cost
of initialising an interpreter and compiling source if fairly
constant. The cost of copying a script object will vary greatly, not
least because AppleScript's inheritance/variable binding systems mean
that you're almost always copying your entire top-level script and all
of its state [1]. (It may even fail completely since AppleScript's
serialisation mechanism can easily blow its buffer limits on large/
complex objects.)
Also bear in mind that because 'run script' copies everything in and
out, any changes it makes to the duplicate script object's state won't
be reflected in the original. If you're trying to do OOP, this is
probably not the behaviour you want.
At any rate, unless you want to perform a runtime 'eval' of source
code or need to sandbox the execution of a portion of code so that it
can't interact with your main program, there's no reason for using
'run script' in the first place - just send a 'run' (or any other)
command directly to the relevant script object and it will handle it,
e.g.:
script Foo
display dialog "run"
on bar(x, y)
display dialog (x + y) as string
end bar
end script
run Foo -- displays 'run'
Foo's bar(3, 2) -- displays '5'
If you want further demonstrations of OOP in AppleScript, I can send
you a zip of the revised AppleMods modules I did a few months back [2]
- several modules, including the module loader itself, use OOP to
varying degrees.
HTH
has
[1] Ditto for using AppleScript's built-in 'copy' command to copy
script objects, another almost invariably bad idea.
[2] With apologies to anyone still waiting for me to boot out a formal
release as previously promised. (While I did start out using them at
work, after a few weeks' raging at AppleScript's many other
shortcomings I persuaded the boss to let me switch to Python+appscript
instead, so I've had very little need and zero free time for them
since.) Basically, if you want 'em, jump up-n-down a bit and I'll fit
them in when I can.
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden