[Pythonmac-SIG] improving appscript architecture

[has]

Hi all,

In the process of rearchitecting appscript as a set of reasonably 
decoupled packages that can be recombined to suit different uses. 
Here's what I've got so far:

     http://freespace.virgin.net/hamish.sanderson/APPSCRIPT2.sit

This contains the following packages:

- aecodecs -- convert Python data to and from AEDescs

- objspec -- extends aecodecs with support for constructing object 
specifiers using raw AE codes, e.g. 
app.elems('docu').byindex(1).prop('ctxt')

- osaterms -- application terminology (aete) parser, plus related 
tools for rendering aete data to constants and documentation

- aeconstants -- used for storing modules similar to 
Carbon.AppleEvents constants generated by 
osaterms.tools.constantsgenerator; may be used in conjunction with 
objspec

- AEM -- creates AEAddressDescs and sends Apple events

- aslite -- 'appscript lite' - extends objspec to allow object 
specifiers to be constructed using application terminology, e.g. 
app('/Applications/TextEdit.app').documents[1].text


The problem I've currently got is with extending the 
objspec.specifier module to add new behaviours to the various classes 
representing object specifiers. There's a lot of composition needed, 
and it's leading to some pretty gnarly inheritance relationships. 
e.g. Look at the objspec.filter module which extends the specifier 
classes with comparison and logical 'operators' for constructing 
filter clauses. I think this one is just about possible to follow. 
With the aslite.specifierplus module - which extends specifier 
objects with support for appscript-style reference - things are 
starting to feel decidedly spaghetti-ish, and can only get worse from 
there. (e.g. I've yet to create a third tier that adds in the 
sanity-checking/constraints and help features that are built into 
appscript 0.5.0. And as for adding hooks to a future PythonScripting 
framework so it can be used in AE server applications... ahhh. Nips 
ma heid just tae think aboot it.)


I suspect what I really want is mixins or a nice prototype-based OO 
scheme, but Python doesn't have native support for either. (There are 
days I really get frustrated by Python's object system, which is both 
too complex and too inflexible, and this is definitely one of them.) 
I could perhaps rig something myself, or I could maybe use 
metaclasses to provide an API that can mix behaviours according to 
recipe to create the required modules, or perhaps some sort of 
facade+delegation scheme using __getattr__, or maybe something else I 
haven't thought of like turning the whole problem over to a source 
code generator.

Given this code needs to be simple, efficient, maintainable and 
extensible - and [ideally] serve as a pattern for folk who want to 
develop similar bridges on other languages - I'm all open to 
suggestions.

Thanks,

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