[Pythonmac-SIG] package structure for OSA interfaces

Jack Jansen Jack.Jansen@oratrix.nl
Mon, 21 Jan 2002 22:01:10 +0100


On Monday, January 21, 2002, at 06:40  PM, Michael J. Barber wrote:

> I've been taking a closer look at the structure of the packages 
> produced by gensuitemodule. I'm a bit confused about the logic 
> of the Standard Suites package. The StdSuites package is used 
> to build packages for other applications, so is a fundamental 
> part of gensuitemodule. As far as I can tell, the structure is 
> suboptimal; hopefully someone can let me know what I'm missing, 
> if anything.
>
> The modules I'm concerned with are StdSuites.Required_Suite and 
> StdSuites.Standard_Suite. The required events are open, run, 
> print, and quit. These four events are defined in Pythonic 
> terms in StdSuites.Standard_Suite rather than 
> StdSuites.Required_Suite. Apps that define the required events 
> in their 'AppleScript Dictionary' work fine with this approach.

There is something going on here that I don't understand, maybe 
someone else knows more about OSA can give me a hint?

It used to be that the required events were declared in the AETE 
resource for Required (which is also where I would expect them, 
reading Apple's documentation). However, as of a few years ago 
(Mac OS 9? The demise of the english dialect file?) Apple moved 
the declarations to the Standard suite. Therefore, in the Python 
suites they end up in the standard suite module, because after 
all the suite modules are generated.

But somehow the inheritance used by (say) Script Editor is 
better than what the Python OSA architecture uses: whereas 
Python sometimes cannot find open (because it's declared in 
Standard in stead of in Required) Script Editor has no such 
problem.

What I would prefer is somehow use a construct that is 
orthogonal to how Apple's suite inheritance scheme works. If 
that can't be done then fixing it up manually is an option, but 
it is not an option I like. First of all there's the problem 
with regenerating the suites, but that is solvable (and should 
be solved: you shouldn't be counting on me to remember doing 
manual edits after I regenerate the suite modules:-). More 
serious is that if the events are defined in multiple suites we 
may end up with the wrong one. Think of the following situation

class StdSuites.Standard_Suite:
	def open(): ....

class StdSuites.Required_Suite:
	def open(): .... # Same as above

class MyApp.Standard_Suite(StdSuites.Standard_Suite): pass

class MyApp.Required_Suite(StdSuites.Required_Suite):
	def open():
		# version of open with, say, an extra optional parameter

clas MyApp(Standard_Suite, Required_Suite): pass

(Phew, that was a long example:-)
Anyway: now MyApp.open will be the wrong method: it will be the 
method declared in StdSuites.Standard_Suite in stead of the one 
from MyApp.Required_Suite!
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- 
Emma Goldman -