Method Underscores? (and a 'solution')

[has]

aleaxit at yahoo.com (Alex Martelli) wrote in message news:<1gm2fs0.1wc9vf61okndnvN%aleaxit at yahoo.com>...
> > Yeah, it does have that Logo-like quality about it, doesn't it? For 
> > beginners, of course, it's typically more interesting to be able to 
> > write scripts to get their computers to do things they'd otherwise have
> > to do themselves, so AppleScript-for-Windows might be a good Python project!

Even better idea: just use Logo! :)

Seriously, the AppleScript language is no great shakes. The only
things going for it are that AppleScript code is easy for
non-programmers to read, and that it's got very good Apple Event
Manager and Open Scripting Architecture support built in. Then again,
AppleScript code is a right pain to write, and the only reason it
remains the popular choice for Mac application scripting is because
most every other scripting language has failed to provide AEM and OSA
support worth a damn. :(


> Yes, but mapping the simple "apple events" on which applescript is based
> (and which are widespread in applications as well as the OS on the Mac,
> e.g. MS Office apps implement them) to COM's richer and more complex
> ways (and COM/Automation enjoys a similar prominence on Windows and its
> applications) sounds like quite a task, requiring deep understanding of
> both platforms.  Maybe I'm being pessimistic...

Any fule could implement a clone of the AS _language_; there's
actually very little to it. Heck, you could probably write a parser
that compiles an AppleScript-like syntax into Python source code
fairly easily. It's the OSA component and IPC stuff that would take
time. The former you could probably do fairly easily using COM, but
for IPC support you'll find Windows' DCOM/WSH to be a VERY different
beast to Apple events, which is basically synchronous/asynchronous RPC
plus basic relational queries. This means that almost all the hard
work to support a _full_ AppleScript clone would be on the
application, not the language, side. Which means not only providing
application developers with suitable frameworks but also persuading
them to use them - no small task to say the least.

An application's Apple event interface is basically a whole additional
View-Controller layer - a peer to its GUI/CLI/web/etc. interface(s) -
built atop the Apple Event Manager/Cocoa Scripting framework, just as
its GUI interface is built with the Application Kit framework. And,
just as there's a whole bunch of rules and guidelines on how GUI
interfaces should look and behave, there's an equivalent for scripting
interface developers. e.g. See Apple's Scripting Interface Guidelines,
a partner to its GUI-oriented HIG,
at<http://developer.apple.com/technotes/tn2002/tn2106.html>.

It's deceptively powerful stuff, though a lot of applications don't
support it nearly as well as they could - or should (many of Apple's
own apps are guilty here). Mac Office apps aren't really a good
example - their Apple event interfaces are really just a thin wrapper
around their VB APIs and quite atypical. Take a look at something like
Adobe InDesign (one of their engineers is Jon Pugh, one of the
original Apple team behind OSA, etc.) - it has very comprehensive and
well designed AE interface, as well as JavaScript and VB APIs.


You probably could implement a Windows clone of the Apple Event
Manager using DCOM or whatever as your inter-process message transport
mechanism, but it looks as if Longhorn will have something fairly
similar to Apple events and the Apple Event Object Model with its
Indigo and OPath technologies, so probably not worth doing now. (Makes
you wonder what might've been had OpenDoc taken off though - it was
built on Apple events and, IIRC, intended to be cross-platform, and
years ahead of its time.)

Mind you, I've already implemented Python libraries for constructing
object specifier-based queries
<http://freespace.virgin.net/hamish.sanderson/appscript.html> and am
working on supporting the Apple Event Object Model in Python, so you
probably could port these to other systems just by replacing the
platform-specific Carbon.AE extensions used for the inter-process
messaging part with XML-RPC, dBus or whatever else is to hand.


Happy to discuss this stuff further if anyone's interested and wants
to take it to a separate thread.

has