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: Thu, 11 Dec 2008 22:45:47 +0000
On 11 Dec 2008, at 13:09, Philip Aker wrote:
AppleScript 2.0 already supports targeting applications by bundle id:
[..]
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.
It's not clear what you mean by 'terminology providers', or what
problem it's meant to solve that isn't covered already.
If you want to specify terminology at compile-time, wrap your code in
a 'using terms from' block. If you want to specify terminology and a
default target for commands, use a 'tell application ...' block with
the application name or bundle id supplied as a literal so that the
compiler can read it at compile-time. If you want to specify a default
target only, use a 'tell ...' block with anything other than a literal
application specifier as the target.
Right now this only works for applications, not for osaxen; if the
same approach was to be applied to osaxen then the language would need
something like a 'scripting addition' specifier (although, as
mentioned before, changing osax scoping rules now would likely cause
more problems than it'd solve).
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.
A one-size-fits-all syntax doesn't really win you anything. Someone
still needs to implement code for connecting to each class of supplier
(application, osax, etc), and in practice that's going to be Apple who
can easily matching object specifiers in the language while they're at
it. Having different specifier names for different classes of
suppliers is also preferable for users as it makes the code more
descriptive and therefore easier to understand.
The only other thing your examples add are an unintuitive phrasing and
extra indirection, neither of which you want in a language like
AppleScript given its target audience. A statement such as:
tell application "Finder" to get name of home
may not satisfy the purists, but it's more than adequate for most
AppleScripters to get started with and easy to understand. It's
certainly simpler for novices to read than:
tell application id "com.apple.finder" to get name of home
while most would be put off by the much more cryptic:
associate fndr with provider "com.apple.finder"
...
tell fndr to get name of home
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.
Moving osax handlers out of processes and into the AS component
doesn't curtail AppleScript's dynamism. It does prevent non-
AppleScript clients using them, but it's not like they'd be missing
much. More importantly, it would plug another potential hole in the
system. If osaxen had been implemented as language extensions from the
get-go Apple wouldn't have had to plug an embarrassing osax-based
security flaw in their OS a couple months back, and users running
AppleScripts within privileged processes wouldn't now find their
scripts unable to load any osaxen at all.
Beyond that, there isn't really much point trying to invent clever,
sophisticated import mechanisms for AppleScript. They're unlikely to
justify their development costs as the language just isn't that good
or widely used, and it creates more complexity for users, most of whom
aren't professional programmers and will benefit more from simplicity
and clarity and the reuse of existing mechanisms.
Regards,
has
--
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