Re: [Pyobjc-dev] Separating functionality into modules

[<bb...@ma...>]

On Sunday, November 17, 2002, at 04:20 PM, Jack Jansen wrote:
> 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?

At the moment, it is the only first-class, high level, OO API included 
with the system that is not highly application specific 
[PreferencesPane, ScreenSaver, Project Builder] and includes a public 
API.   It is generically useful and represents functionality that quite 
a number of developers will want to use.

With that said, no, there isn't any particular reason why it needs to 
be a part of the core PyObjC project.  Certainly, for app distribution 
services, being able to trim out chunks is attractive in that it 
reduces size.  However, we already have that ability -- just don't copy 
AddressBook or AppKit into your distribution, if you don't need them.

I could go either way on this one...

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

Before we go here, how much functionality are we actually talking 
about?   There is the Nib loader in AppKit and a handful of utility 
functions in Foundation (convert between Python and ObjC collections -- 
need to do the other half of that someday), but a lot of the 
functionality is glue that makes the various classes behave better on 
one side of the bridge or the other.

I used pprint(dir(Foundation))...

Now, I can certainly imagine that the glue will grow over time, but-- 
likely-- not to a huge degree.

I like the idea of prefixing things with 'PyObjC' -- the extra 
characters guarantee we won't hit a conflict and make it clear where 
the functionality is coming from.  I.e. AppKit.PyObjCNibLoader -- or, 
maybe better?, AppKit.pyobjc.NibClassBuilder or 
AppKit.PyObjC.NibClassBuilder?    Actually, AppKit.Python.... isn't 
that bad either, but using 'Python' leaves us open to namespace 
conflicts (what if a developer provides a 'Python' class in their 
runtime?)

> 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")

It requires a compiled component to wrap a framework such that 
enumerated types, #defines, and functions can be exported.  Ronald has 
done an amazing job of automating the generating of the wrappers, but 
it needs some work before it could automatically generate a module 
project to wrap a specific framework.  That would be very, very cool...

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

Agreed.

> 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).

Yes;   how about something like....

 >>> sys.version_info
(2, 2, 0, 'final', 0)
 >>> sys.version
'2.2 (#1, 07/14/02, 23:25:09) \n[GCC Apple cpp-precomp 6.14]'

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

Agreed.   Depending on which direction the GnuStep port takes, we could 
end up with two Foundation and two AppKit modules that are on 
differently development tracks.   Maybe even something that works like 
os.path that makes the fairly severe differences between different 
implementations of the AppKit relatively transparent.

And if Sun were to ever break out their implementation of the AppKit 
(which was pretty damned excellent, btw), then we would already have 
the code in place to handle yet-another-variant. :-)  (No, I don't 
believe there is a chance of that happening... but strangers things 
*have* happened.)

b.bum