Re: Tell Blocks Considered Harmful (was Re: open for access)
Re: Tell Blocks Considered Harmful (was Re: open for access)
- Subject: Re: Tell Blocks Considered Harmful (was Re: open for access)
- From: has <email@hidden>
- Date: Wed, 10 Dec 2008 22:36:55 +0000
Philip Aker wrote:
What I'm trying to
illustrate is an upgrade to 'tell application "XXX"' such that the
terminology association and interpretation is associated to the bundle
id rather than the application name (tell bundle id "XXX").
AppleScript 2.0 already supports targeting applications by bundle id:
tell application id "com.apple.finder"
home
end tell
Simple, readable, and works; 'nuff said.
As for scripting additions, it would be better that they lived
completely in their own namespaces instead of polluting both
AppleScript's global terminology and processes' event handler tables,
e.g. something like:
tell scripting addition "StandardAdditions"
beep
end
However, I can't see that particular change happening and wouldn't
recommend it anyway, as it would cause massive breakage of existing
AppleScripts (which all expect osax terminology and handlers to be
globally available).
What could (and should) happen though is that the task of loading and
invoking osax handlers should be moved out of processes and into the
AppleScript component itself (which is where it should've been in the
first place). Allowing the arbitrary loading of arbitrary code into
arbitrary [1] processes just isn't a very good idea, and Apple are
already in the process of locking down that sort of behaviour
elsewhere (c.f. Input Managers).
Instead, let the AS component maintain its own private table of osax
handlers and give that table an opportunity to intercept and respond
to any outgoing Apple events before they're sent on to the target
application. It'd be a very cheap and largely non-disruptive [2] way
to turn the existing osax setup into a language extension mechanism
with only minimal breakage of existing AppleScript code [3]. OSAX
terminology and handlers would still be globally available within
AppleScript, but that'd be the limit of their scope.
Regards,
has
[1] Or, since the last security update, arbitrary non-privileged
processes.
[2] I think creating a brand new extension mechanism - while it
might've been a worth doing a decade ago - would be a complete waste
of time and resources at this point in AppleScript's life. (I can
think of plenty more productive ways for the AS engineers to invest
their days if they get bored for something to do.) In addition,
AppleScripters would be seriously unhappy with any change that
significantly breaks their existing scripts or doesn't work with their
existing osaxen.
[3] Of course, it'd break all non-AppleScript-based code that
currently relied on osaxen (e.g. anyone using appscript's osax
module), but that's a small minority of osax users and they should be
able to find better native alternatives anyway.
--
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