[Pythonmac-SIG] Applescript

[has]

Jack wrote:

>I'm going to read and understand all the stuff you answered some 
>time tomorrow,

Good luck! <g>

>and then I'll incorporate it into a second version of "The 
>AppleScript architecture as Jack understands it", and I hope we can 
>have a second round over it, so eventually we should hopefully end 
>up with something that is understandable (at least to me) and 
>correct (at least according to you:-).

:) Sounds good.


>In the mean time there are two issues still open:
>
>>>>>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].
>
>Could you elaborate on this, please? If it means we should use 
>another paradigm for Python scripting support (or at least allow 
>escape from the OO paradigm to the other, presumably lower level but 
>richer paradigm) it is important.

Well, I've followed AppleScript's approach, which is to do the 
query-building thing, then cover it with syntactic sugar to make it 
look and feel pleasant and familiar; eg:

- AppleScript:

    a reference to first character of every paragraph of text of 
document "ReadMe.txt"

- Python:

    app('TextEdit.app').documents['ReadMe.txt'].text.paragraphs.characters[0]


Whereas the unsugared form would look like:
 
app('TextEdit.app').elems('document').byName('ReadMe.txt').prop('text').elems('paragraph').elems('character').byIndex(0)

Now this is perfectly usable (it's part of my 'generic API' 
specification), and for languages that don't provide any options to 
sugar it it's probably the only way to do it. But I doubt anyone but 
a masochist would ever _want_ to write it this way, at least not if 
they have any sort of choice. ;)

<sidenote>

IMO, one of the ironies of the AEM API, at least as it applies to 
scripters, is that had its designers cooked up some cheesy 
mini-language using some sort of crude SQL-ish syntax, we wouldn't 
all be in the fix we are today with folks confusing it for something 
else. Mastery of such icky crap would be a respected artform. 
Eventually, of course, some smart cookie would write a module that 
wraps all the nasty string-munging nonsense behind a nice 
programmatic API; and so on...<g>

Seriously though, I have considered writing such a beast, using, say, 
a hybrid syntax that'll look unfamiliar enough to avoid folk forming 
premature misconceptions about how it works. My knowledge of parsers 
is just about good enough, and of course Python has some excellent 
tools for building them. And maybe I will do this someday; it might 
have some value for folk who like the CLI, for example. But right now 
it'd just be a big ol' diversion for which I don't have the time.

</sidenote>

So I think we should go with the syntax we have. We just need to grab 
newcomers for the first five minutes - so they don't go looking at 
the syntax and forming any silly notions of how it works - while we 
explain to them that 'application scripting is hierarchical 
relational blah-blah-blah'. Some sort of <bam!>in-your-face, one-page 
'Introduction to Application Scripting for Python' document, full of 
big type and pretty pictures. Something to plan for. You think?


>Second question: from your remarks I assume that we could call the 
>class/object/terminology stuff a layer. Does this layer have a name?

The terminology resource is just that: a resource; 'metadata' as Bob 
put it. It's not a layer, but it's freely available to any layers 
that might wish to use it.



>Do you happen to know of a sure way to get at terminology 
>information? Script Editor always manages, but I seem to manage only 
>in about 30-40% of the cases, and even then often with hacks.

OSA's GetAppTerminology() ought to work - it _is_ the formal API for 
this, after all. I know Donovan's GetAppTerminology wrapper hasn't 
had much luck recently with this (he doesn't seem to know why 
either), so if you're having trouble with your own OSA wrapper then 
the best thing to do would be to post your problem to the AS 
Implementors List:

    <http://www.lists.apple.com/mailman/listinfo/applescript-implementors>

Chris Nebel, one of the Apple engineers appears on there on a regular 
basis, and there's quite a few experienced developers that frequent 
it too. If it turns out that the problem is with OSA rather than 
anything on your side, it's something that'd merit lighting an 
almighty fire under Apple to fix asabp.

If that doesn't get you anywhere, I'm on friendly terms with one of 
the Satimage guys (they do the Smile editor) and could try mining him 
for info.

HTH

has

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