|
On 22/11/2013 07:20, Chris Page wrote:
Hi Chris, apologies for my slow response to your slow response...
:)
On Jun 29, 2013, at 11:14 AM, has <email@hidden>
wrote:
One thing those notes
don't mention (but probably should) is that OS X
support for third-party
OSA languages is effectively dead now. While
third-party support for
Apple event/OSA technology was pretty much
spannered after 10.6
legacy-ed the Carbon Apple event APIs anyway,
10.8 goes much further by
aggressively deprecating the Component
Manager which, amongst
other things, was the system used to package
third-party languages as
OSA components.
There are many gradations of “deprecation”. Without
more-explicit statements, “deprecated” means “not recommended
for new development.”
TBH, that sounds more like Apple's definition of 'legacy API', e.g.
the Carbon Apple Event Manager. Apple's public documentation is
quite clear on how users should read 'deprecated API': e.g. from the
'
Deprecated Component Manager Functions' section of the Component
Manager Reference:
"A function identified as deprecated has been superseded and may
become unsupported in the future."
While I'm sure Apple keeps internal roadmaps for all its legacy and
deprecated APIs, us poor folks on the outside don't get to see those
so have to go by what's published. And the public warning seems
pretty clear that building new code on top of deprecated APIs is a
_bad_ long-term investment. FCPX, for instance, showed that Apple
isn't afraid to bork customers' existing workflows in modern
fully-supported products with zero notice. Even having to rely on
legacy Apple stuff make me antsy as hell [1]; there's no way in hell
I'd trust my own or my customers' future to anything on Apple's
public deprecation list. I'm stupid, but I'm not *that* stupid.
Heck, Apple's own Audio team dumped CM like a rock at 10.7, a full
release _before_ it was publicly deprecated: in absence of explicit
statements, that's as close to an official warning that the CM has
had it as outsiders are likely to get.
If there are deprecated APIs without replacements that you
need, file a Radar describing your needs. OSA component
support is still working fine. It’s how AppleScript works.
OSA may still 'work', but it's disingenuous to pretend it's anything
other than one of the Walking Dead.
There are no OSA languages other than AppleScript, and never will be
again. All past attempts to provide users with alternative language
components have withered and died, partly due to the technological
limitations of the OpenScripting architecture, partly due to Apple's
failure to explain how to write the wretched things. AppleScript
Editor's 'languages' menu broke years ago and AFAIK has never been
fixed. (And why bother, when there's only ever one choice anyway?)
The only surviving third-party OSA component is Late Night
Software's AppleScript Debugger component, itself a hacky workaround
for AppleScript's own notoriously absent debugger support.
OSA as it exists today is a twenty year old architecture designed
for a far simpler and naive hardware and software platform. It knows
nothing of modern memory management, networks, security, and
sandboxing. It's never even heard of CoreFoundation, Cocoa or
Objective-C. It's shackled to Apple events and a whole bunch of
other ancient unloved Mac-only Carbon technologies, making it an
unhappy fit for Cocoa-based developers and a total non-starter for
ever crossing over to iOS. Its System 7-era in-process hosting model
is utterly unsuitable for both sandboxed applications and most
scripting languages, including very popular ones like Python and
Ruby, all of which require scripts to run in separate sub-processes
for security and reliability. [1]
At this point, Apple is just piling hack upon hack to keep it
limping along at ever decreasing levels of usefulness. e.g. See
NSUserAppleScriptTask, which is even less functional than the
notoriously lame NSAppleScript (which at least provided some
persistence support) and way more painful to use than
NSUserUnixTask. And it doesn't even pretend to recognize anything
other than AppleScript, whereas NSUserUnixTask lets you run scripts
written in just about any language, including AppleScript.[2]
With every new OS X release, OSA gets more and more useless and
irrelevant. Most developers already regard the entire AppleScript
stack as damage to be worked around or avoided completely, which is
why we see various applications embedding their own
_javascript_/Python/Ruby/Lua interpreter and implementing their own
ad-hoc interfaces to allow that interpreter to manipulate the host
application. That's precisely the sort of wildly inconsistent
user-hostile fragmentation that OSA was originally intended to
prevent, but now just exacerbates. I tihnk the only reason it's
still in OS X at all is because nobody even cares enough to rip it
out. An Apple engineer could easily de-componentize the AppleScript
interpreter and hook it directly to the OpenScripting APIs in a few
hours, and AppleScript would continue to work _exactly_ the same as
before. The only difference would be that Script Debugger's current
hacky 'AppleScript Debugger' component would no longer load, but
without OSA blocking the way you could add a proper debugger API to
AppleScript much more easily - an improvement that'd hugely benefit
ASE and Xcode/AppleScriptObjC users as well.
The fundamental concepts and objectives underlying the AppleScript
language, the Apple Event Object Model and the OSA component system
are absolutely brilliant - but the whole lot's been sliding downhill
on the design, implementation, documentation and marketing ever
since. It'd be unrealistic to expect all these problems to be fixed
at once, but as the least used and least useful of these
technologies, OSA would be the obvious place to start. As long as
the current OSA remains firmly wedged in OS X's nethers, it provides
Apple the convenient excuse not to bother creating a modern, robust,
secure, and genuinely useful successor: why invest in OS X's
scripting support when nobody uses it? There are thousands of app
developers and power users who currently won't touch anything
AppleScript, but accept the burned-out OSA and embarrassingly poor
NSUser*Task are just wasting everyone's time, and replace them with
a modern, sandbox-safe, truly language-independent plugin framework
that actually meets those users' needs, and you might start
(re)building some much needed bridges with those audiences, and
break the current Catch-22.
Disrupting the status quo is what turned Apple from an industry
laughing stock to world leader. Applying the same attitude to
AppleScript's world might help turn it from shrinking ghetto to
something that starts to do Cook et al's original vision proud.
It would be nice to see.
Merry Christmas,
has
--
[1] Python and Ruby scripts need to run in separate [sub-]processes
because their interpreter implementations are riddled with globally
shared state, which means two completely unrelated scripts running
in the same process (as OSA does) can freely stomp all over each
other's state, creating no end of exciting and
impossible-to-diagnose malfunctions and errors.
Ironically, the latest AppleScript release is no longer OSA-safe
either since it caches loaded libraries at the per-Component
Instance level rather than per-script; thus two unrelated
AppleScripts loaded into in the same CI can similarly conflict if
they happen to use the same libraries and those libraries contain
settable properties.
[2] Honestly, if an app developer were to ask me how to add
attachability today, I wouldn't even bother with
NSUserAppleScriptTask. I'd just tell them to use NSUserUnixTask and
tell AppleScripters to save their scripts in text format with
'#!/usr/bin/osascript' at the start. And to go bug Apple to provide
a language plugin system that doesn't suck monkey nuts, of course.
|