[Pythonmac-SIG] Applescript

[has]

Michael J. Barber wrote:

>OK, things are becoming clearer to me. I'm going to summarize briefly.
>
>We've got several pieces that work together. Of particular interest 
>to us are AEM, OSA, and the so-called object model.

"application object model"


>The object model may be part of the OSA API, [...]
>I'm still sort of unclear on that; regardless, it is something that 
>is worth focusing on specifically, because it is what we'll normally 
>deal with when we write a program depending on IAC.

To summarise:

- Each application implements its own scriptable object model. (Which 
may or may not follow the structure of its actual Model layer - but 
this isn't something that users ever need to think about.) 
Essentially this is just another User Interface; peer to other 
application user interfaces such as GUI, CLI and Web-based. Just 
pushen ze buttons and watchen das blinkenlights.

- AEM defines the structures used to specify an object, a property, 
an element or elements, and so on; as well as a bunch of structures 
for representing basic datatypes such as strings, numbers, lists, etc.

- OSA is merely a mechanism for componentising your scripting 
language, for those that like to plug-n-play different languages into 
their environments (script editors, attachable apps), plus a couple 
of general calls for getting terminology resources.

Does this help?


>AEM has a relational nature, which masquerades as object oriented in 
>AppleScript and most Pythonic approaches, due to the focus on the 
>object model.

Well, it _looks_ like OO, at least superficially.


>The object model provides a convenient way for getting to the AEM. 
>OSA provides ways for, e.g., scripting languages to interact with 
>AEM.

See summary above.


>OSA and AEM are complementary, but distinct.

Yes.(!)


>There are then several issues:
>(1) The structure of the interface to AEM.

A pig-ugly bucket of loose parts. Very much Do-It-Yourself. Best 
hidden under a higher level interface.


>(2) Making one or more convenient interfaces to the application 
>"object model" for the programmer.

I think I get your meaning. To be a bit more precise: we write a 
module that connects to the AEM. This allows the scripter to 
manipulate an application's object model by calling the module's API.

This is what I'm doing: appscript is a Python-specific implementation 
of a friendly, intelligent high-level API. The generic API I'm 
designing will provide a common pattern for developers on other 
languages to follow when implementing their own high-level AEM 
interfaces.


BTW, I'm even wondering if it'd be worth doing an implementation of 
the generic API in C/C++/Obj-C. This'd reduce the amount of work 
needed to write a module for any language even further: basically one 
would just write a wrapper around this API, plus whatever syntactic 
sugar seems appropriate. Which is a lot more convenient than building 
directly atop the low-level AEM API, where each developer has to 
reimplement all the generic API logic themselves; hardly a good 
example of portable code reuse.


>  An OO package is a common approach, but we should recognize that 
>such an approach may not give a perfect fit to (1).

That depends on what you mean by an 'OO package'. Both appscript and 
aeve are implemented using OOP, but their APIs are very different. 
Appscript creates 'selectors': objects that describe a path to one or 
more objects in the application object model. Aeve builds a proxy 
object model representing the structure of the application object 
model. Appscript fits perfectly with AEM because it simply presents 
what's already there, though at a higher-level. Aeve suffers a bit of 
impedance mismatch because it imposes an OO worldview on top of a 
relational one; but that's by choice, not necessity.


>(3) Making python into an OSA client, minimally for fetching the 
>terminology needed in (2)

Yep.


>and more ambitiously for making Python into a component language 
>like AppleScript or JavascriptOSA.

IMO the main advantage of this - at least in theory - is that it'll 
allow you to attach Python scripts to attachable applications. 
(Attachability is one of those terrific ideas that's currently much 
under-used and under-supported, but could really take off if PerlOSA 
and PythonOSA started bringing in lots of new users for it.)

In practice, there may be problems with attachability from our POV, 
as so far the Cocoa frameworks only seem to support AppleScript. 
(Perhaps they forgot what the 'Open' part of OSA means?) Personally, 
I think full OSA support will only really become useful if we can 
persuade Apple to improve their frameworks or create our own 
GenericOSALanguage class and try to persuade application developers 
to use it in place of NSAppleScript. Though you'll still get some 
benefits, such as the ability to edit Python scripts from Script 
Editor, etc.

I'd also mention that Philip Aker (who I know from my AppleScript 
days) is working on a generic OSA language component framework, based 
on the work he's done on a TclOSA component. Definitely something to 
explore before going ahead with a PythonOSA.


BTW, I'll add a (4) here: designing and building a Python 
module/framework that'll make it easier for folk developing 
full-blown Mac apps to add scriptability. It's something at the back 
of my mind while working on appscript, as appscript will provide a 
good foundation for Python apps to interpret _incoming_ events in 
addition to generating outgoing ones as it can already do. Of course, 
there'll be a lot more to do on top of that, which is why I'm not 
going to think any further on it till stages 1 to 3 are complete.


There may also be opportunities for cross-pollination between what 
we're doing and plans to improve OSS application scripting support by 
other parties; e.g. see the Shuttleworth Foundation's bounties page 
for 2004.

So there's lots of interesting possibilities to explore - once we've 
nailed all the basic stuff down first, of course.


>These issues interact, but are not identical.

Yes.


>Treating them as the same could result in some unnecessarily strong 
>coupling that leads to those "bone-juddering crunches."

Agreed. My gut feeling on Cocoa's built-in scripting support is it 
already has excessively tight coupling between AEM, OSA, AppKit and 
AppleScript. And if there's one thing I've learned over the years 
(the hard way, what else?!;), it's to keep tasks small, simple, and 
well separated. (Of course Unix already taught us this thirty years 
ago... So sue me, I'm a slow learner.;)

Dunno about you, but I think we're starting to make some damned good 
headway too, all thanks to this thread. Pats on back all round will 
be due at the end. <g>


>Gah, I'm feeling TLA burnout...

I'm just feeling burnout. ;)

HTH

has
-- 
http://freespace.virgin.net/hamish.sanderson/