Apple Event Object Model alternatives [was: Re: AppleScript]
Apple Event Object Model alternatives [was: Re: AppleScript]
- Subject: Apple Event Object Model alternatives [was: Re: AppleScript]
- From: has <email@hidden>
- Date: Sat, 8 Dec 2007 03:18:22 +0000
Paul Scott wrote:
Personally, I'd like
to see AppleScript replaced by ECMAScript with a DOM-like
AOM (Application Object Model) interface.
Actually, that's two completely independent requests: one to replace
the AppleScript language, and one to replace the current Apple Event
Object Model used by scriptable applications.
My thoughts on the second request are below; see my previous post for
discussion of the first.
-------
Request Two - replacing the Apple Event Object Model - won't happen
either as there are too many applications currently implementing it,
either from scratch or on top of existing AEOM frameworks such as
Cocoa Scripting, and too many existing scripts written against those
applications. Again, just yanking the current system and replacing it
with something else would cause a firestorm, not just from application
developers angry at having to rewrite their existing application code
to use the new system, but also from application scripters angry at
having to rewrite their existing scripts to work with these redesigned
applications.
That said, Apple *could* - if they wished - design an alternative
event handling framework that new applications could immediately adopt
instead of Cocoa Scripting, or which existing applications could
gradually switch over to at a pace their users could bear. Third-party
developers could also develop their own free or commercial frameworks
for application developers to use.
If anything, creating a full alternative to the AEOM would be easier
than creating a full alternative to AppleScript, since you only have
to convince application developers to use it, and given what a pig it
is to implement a good, reliable AEOM (i.e. somewhere between
Sisyphean and NP-complete) that could actually turn out to be a
surprisingly easy sell if the new system is good enough.
With careful design and comprehensive testing, it should be possible
to create an alternative to the AEOM that retains most of its benefits
and adds several new ones while eliminating all of its problems, yet
still be usable from existing OSA languages (an absolute requirement,
natch). Obviously it won't be quite as aesthetically pleasing (set-
based operations with relational queries are teh Pretty), but at
least it would be straightforward to implement and fast and simple to
use and would have the additional advantage of being an easier sell to
regular object-oriented developers and scripters (of which there are
many) who don't understand or like all that weird RPC+query stuff
anyway.
While there's no obvious sign of Apple undertaking such a venture at
this point, I do see one sign that they might just be vaguely amenable
to this idea: Scripting Bridge's somewhat ham-fisted attempt to hide
the AEOM's true RPC+query nature behind a faux-OO facade. This
suggests that the AppleScript team itself is either growing
embarrassed at the AEOM's fundamental failings, or at least
acknowledging that its RPC+query-based approach isn't much liked by
more than a few folks who'd much rather have a conventional (i.e.
simple and reliable, if boring and unsophisticated) object-oriented
system instead.
Don't get me wrong: I love the concept behind the AEOM and will
continue supporting it in appscript and trying to educate Python, Ruby
and ObjC users in its use. However, it doesn't take a blind man to see
that it was an overly ambitious idea in theory, and the steep (if not
insurmountable) technical challenges it creates - not just to the
Cocoa Scripting engineers but to every single application developer
who wants to add scriptability to their products - are a serious
disadvantage in practice. Given that the primary technical reason
behind the AEOM's design - the utterly abysmal multitasking support of
the original Mac OS - is no longer an issue with OS X, it may well be
that moving to a less sophisticated but easier to understand and 100%
reliable alternative would be a worthwhile trade-off, providing a
significant overall improvement that benefits all parties.
-------
Anyway, if anyone wants to discuss either of these issues seriously, I
would suggest taking them to separate threads over on AppleScript-
implementors which is more appropriate for these sorts of heavily
technical discussions. Otherwise, please feel free to cogitate at your
leisure.**
Regards,
has
(** Though please note that anyone crying "burn the heretic" gets a
thick ear as I'm not in the mood.)
--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org
_______________________________________________
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