Re: [Pyobjc-dev] Separating functionality into modules

[Jack J. <Jac...@or...>]

So let me see whether I understand the separation, and give some other 
random musings.

1. objc contains the bridge: magic glue that the Python programmer 
doesn't see,
    plus stuff that is essential for talking to any ObjC based 
framework. It
    depends on Foundation, but this is also true for ObjC programmers, 
really.
2. Foundation is a one-to-one mapping of the Foundation framework. Some 
of the
    classes may have more functionality on the Python side, some less, 
but that
    is minimal and should be "reasonably obvious".
3. AppKit idem ditto.
4. Why AddressBook is included completely eludes me. Is this framework 
somehow
    more important than the other ones, or is this really only an 
example?

We need a new place to put Python-specific modules, at the moment only 
for
AppKit but later we may want this for the other packages too. I can see 
two simple solutions:
A. Put them in a sub-package. Foundation.Python comes to mind, but 
there may
    be better names.
B. Prefix them with "Py". Again, another prefix is also possible.

If for (4) I'm correct and AddressBook is just an example, shouldn't we 
provide a general solution in the form of a factory function so the 
user can do
AddressBook = Foundation.Python.GenerateModuleForBundle("AddressBook")

As to documentation: documenting the bridge (i.e. the objc package) is 
the most important. This is the documentation that everyone will need, 
including seasoned ObjC programmers. Second comes more user-manual 
style documentation, such as instructions for integrating Python code 
and ObjC in PB and using IB from Python (this sort of thing is more 
easily learnt by studying examples than the bridge itself, hence I 
think the objc documentation is the more important one). Third comes 
the documentation describing the differences between our 
Foundation/AppKit and ObjC's one.

Oh yes: I want a version number somewhere, probably in objc. I don't 
really care whether there's a static version number or a function that 
returns a version number, but I need a version number for my Python 
Installation Manager (which will help keep the size of MacPython 
distributions down, but still allow pretty easy access to any package 
for end users; see the pythonmac-sig discussions for more details).

Actually, why not put a version number in everything? I can imagine 
updating AppKit (because Apple has added functionality, for instance) 
without necessarily updating the rest.
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -