Re: on OSA (was Re: What's so great about AppleScript, anyway?)
Re: on OSA (was Re: What's so great about AppleScript, anyway?)
- Subject: Re: on OSA (was Re: What's so great about AppleScript, anyway?)
- From: has <email@hidden>
- Date: Sat, 20 Dec 2008 17:10:40 +0000
Chris Page wrote:
I do think OSA is a win, in that it gives you a generic way to run and
manipulate scripts that may have completely different syntaxes and
runtimes.
The concept behind OSA is pure gold. The implementation we have today
is a total failure in every way that counts, and needs to die. In
fact, OSA is going to die eventually anyway - the only question is:
will it be because Apple create a new, killer API to replace it, or
because application developers resort to embedding their own preferred
interpreters (as some already are).
Personally, I would love to recommend a language-agnostic approach to
application developers as it empowers a greater proportion of their
users and enriches the Mac automation environment as a whole; however,
this option simply does not exist in any meaningful form. Given the
choice between using OSA or directly embedding a Python/Ruby/Lua/
JavaScript/etc. interpreter, I'm forced to agree with the choice that
developers who don't have a specific tie for AppleScript seem to be
making, which is to go the embedded language route [1]. This may be
annoying for users who would prefer to work in their own favourite
language instead of a language mandated by the application, but at
least it works.
Unfortunately, OSA as it exists today is a bit crufty and
harder to add new languages to than it could be.
To put it very, very, very, very mildly. [2]
Philip's already talking about what he sees needed in an OSA
successor, although I'm not sure if he still envisages it being built
atop the existing OSA/Component Manager set-up rather than being a
green-field development.
Unfortunately, I haven't had time to keep up with all of the
discussions going on right now, including this one, but completely
agree on features that Philip has proposed such as plist-based
component description and Core Foundation API. I would also add:
- language components are CFBundle-based
- toll-free bridging of its APIs to ObjC/Cocoa
- complete independence from Apple events (the two technologies may be
synergistic, but they should *not* be inter-dependent [3])
- out-of-the-box support for out-of-process hosting (both per-
interpreter and per-script) in addition to in-process hosting.
Anyway, if Apple want to make a serious commitment to designing and
developing a completely new language component architecture that
doesn't suck, I'll be amongst the first to welcome it and happy to
contribute whatknowledge and experience I can. That said, I'm not
inclined to spend lots of time and effort preparing carefully thought-
out design criticisms, feature requirements, etc. for Apple's benefit
without some sort of reassurance that I'm not just talking into thin
air (again).
Regards,
has
[1] Don't forget that using the OSA effectively ties your application
to AppleScript for anything but the most menial of tasks, so using OSA
is in practice no different to choosing any other single-language
solution.
[2] I may have omitted a few "very"s for space.
[3] 1. Heavy coupling is poor design. 2. Making OSA reliant on the
Apple events deters developers who would otherwise benefit from
language agnosticism, but have no need or desire for the mental,
technical and performance overheads of Apple event-based communication.
--
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