[Pythonmac-SIG] Applescript

[Michael J. Barber]

On Thursday, Jan 8, 2004, at 16:52 Europe/Lisbon, has wrote:

> Michael J. Barber wrote:
>
>> I'm not at all sure I that I understand the consequences of this 
>> fact, though. Specifically, what does this say about how Python 
>> should look as a substitute for AppleScript? Is the 
>> gensuitemodule-style approach of making an OO package that mimics the 
>> application dictionary just fundamentally misguided?
>
> It CAN be done this way: gensuitemodule does it, as does aeve. And 
> proxy objects/object models are not an uncommon idea: psyco does it, 
> Cocoa does it, plenty of others do it too.
>
> The question is: is this the most efficient way of doing it? In my 
> considered opinion, no. Because
> what you really want to model in your own API is not the application 
> object model, but the various AEM reference forms. Because that's the 
> bit that really matters. The application's scriptable 'object model' 
> is simply a user interface, no different to a GUI dialog with buttons 
> and fields for users to click on as they wish. And the application 
> dictionary is merely the user documentation for this interface, along 
> with some mappings to convert from human-friendly names to AppleEvent 
> codes for those clients, such as AppleScript, who wish to use them. 
> Trying to read anything more into them can be done, but personally I 
> see it as just creating a lot of unnecessary complexity. Not to 
> mention the bone-juddering crunches that shifting paradigms without a 
> double de-clutch can cause...;) [3]
>
>
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. 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. 
AEM has a relational nature, which masquerades as object oriented in 
AppleScript and most Pythonic approaches, due to the focus on the 
object model.

The object model provides a convenient way for getting to the AEM. OSA 
provides ways for, e.g., scripting languages to interact with AEM. OSA 
and AEM are complementary, but distinct.

There are then several issues:
(1) The structure of the interface to AEM.
(2) Making one or more convenient interfaces to the application "object 
model" for the programmer. An OO package is a common approach, but we 
should recognize that such an approach may not give a perfect fit to 
(1).
(3) Making python into an OSA client, minimally for fetching the 
terminology needed in (2) and more ambitiously for making Python into a 
component language like AppleScript or JavascriptOSA.

These issues interact, but are not identical. Treating them as the same 
could result in some unnecessarily strong coupling that leads to those 
"bone-juddering crunches."

Does that seem approximately correct?

Gah, I'm feeling TLA burnout...

-- 
Michael