[Pythonmac-SIG] Applescript

[has]

Michael J. Barber wrote:

>>>>>BTW, one other thing: it'll save you a LOT of mental anguish if 
>>>>>you realise from the start that application objects are referred 
>>>>>to using basic relational queries [4]. Most folk don't realise 
>>>>>this, especially since AppleScript uses syntax that looks much 
>>>>>like standard OO [5].
>>>>>
>>
>That is an extremely interesting comment. I've certainly never 
>considered that point of view before, but it seems to address some 
>of the murkier aspects of AppleScript's "object oriented" behavior.

Mind that I'm talking about the behaviour of the Apple Event Manager 
and applications' scripting interfaces here - not about the 
AppleScript language. The AppleScript language - as a client of these 
services - exposes these behaviours directly to users. Meanwhile it 
has its own set of rules governing its own objects.

What trips almost everybody up is that both application objects and 
language objects are represented in AppleScript using the _same 
syntax_. So folk, going (not unreasonably) by appearance, think 
they're one and the same when in fact they are completely separate 
entities.

Language objects behave according to one set of rules; application 
objects behave according to another.[1] This is _very roughly_ 
comparable to the distinction you have between Python types and 
Python classes, only the division is far, far greater. Because not 
only are there differences in behaviour caused by differences in 
implementation, you also have differences due to the fact that each 
follows a different paradigm! That is, OO for language objects versus 
relational for application objects, although both operate on a 
hierarchical model.[2]


>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]


>At any rate, thanks a lot for this message! I've found it really 
>thought provoking and informative.

I'm only too happy to [try to] explain this stuff as best I can. 
Apart from anything else, it helps me to hone my own thinking and 
learn how to express these ideas better to others (i.e. gratitude 
means I done okay, raspberries means it's back to the ol' drawing 
board tomorrow;). The main reason though is that unless there's a 
body of other folks out there who also totally 'get' this stuff then 
it won't matter a toss if I create the best AEM bridge in the whole 
damn universe, because nobody else is ever going to care about it but 
me! <g>


Therefore, consider your mission - should you choose to accept it - 
to read, comprehend, filter, critique, refine, recycle, extend, edit, 
format, present and finally disseminate anything good that comes out 
of these posts as far and wide as you possibly can. (Note that I'm 
going to collect them later on my website, just as a matter of 
record. But I won't pretend that it's anything more than a bunch of 
ad-hoc thoughts of variable quality tossed together on the fly, and 
for the time being at least I'll have to leave it to others, like 
yourself, to make something more useful out of it.)


5...4...3...2...1...

has


[1] That some of the rules for one may be similar to the rules for 
another is neither here nor there. If anything, any similarities just 
cause more confusion amongst users when they encounter the 
differences.

[2] i.e. Please don't start thinking 'tables' a-la SQL when I use 
such hot-topic words as 'queries' and 'relational', or I'll be even 
more embarrassed...;)

[3]  Or: "How to restrict yourself to the subset of AEM's useful 
behaviours that can be shoehorned into an OO paradigm without really 
realising." Or: "Welcome to a whole new world o' pain!" Or...
(No offence to Bob, or anyone else, intended!)
-- 
http://freespace.virgin.net/hamish.sanderson/