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: Philip Aker <email@hidden>
- Date: Thu, 11 Dec 2008 05:09:22 -0800
On 2008-12-10, at 14:36:55, has 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
Well, I think you misinterpreted my lousy illustration :-). It was
intended to show how "terminology providers" will be an upgrade to
'tell application "XXX"' not how to upgrade the existing facility. One
reason for using a bundle id or a URL is because the nature of the
packages located can be determined. So a "terminology
provider" (assuming it subscribed to the required protocols) wouldn't
necessarily be limited to the application or osax packages currently
used because if the nature of a package can be determined, the means
to load/activate it can also. I believe the terminology provider
concept is in keeping with AppleScript's marked tendency for
polymorphism and would save the implementor from mucking about with
the existing methods.
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).
Terminology providers, as a new mechanism, would not break existing
scripts.
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).
It seems to me that the above implies some curtailment of dynamism and
therefore not advantageous. Besides, the osax format is now remarkably
similar to plugins and the plugin notion is fully supported by the
system -- in fact one of the characteristics of Mac OS X if you
realize that the default format for code hunks is that of a dynamic
library.
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.
Kinda sounds good, but I'm not sure of the full implications of the
interception idea right now. I'd need a bit of a hint as to how it
would handle private osaxen too.
Philip Aker
echo email@hidden@nl | tr a-z@. p-za-o.@
Democracy: Two wolves and a sheep voting on lunch.
_______________________________________________
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