[Pyobjc-dev] Separating functionality into modules

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

On Saturday, November 16, 2002, at 07:18 PM, Jack Jansen wrote:
> What I do wonder, though, is whether this should be in AppKit. 
> Shouldn't we try to keep AppKit clean, so the Apple documentation 
> completely describes it, and put our own PyObjC-specific stuff 
> elsewhere? There isn't a good place right now, I think, but now might 
> be a good time to add one ("PyObjC" comes to mind as a name). Or does 
> the objc package fit this bill?

[The NibLoading mechanism] It makes more sense in AppKit than it does 
in objc.   The PyObjC bridge can be used outside of the context of the 
AppKit -- the AppKit is just a framework that adds a set of classes for 
use within ObjC.   Same goes for Foundation, technically -- the NSArray 
and NSDictionary glue should be moved into Foundation.

That objc mixes in bits from Foundation and AppKit is a bug, really -- 
though it also seems unavoidable in some cases.  The objc module should 
provide only what is necessary to provide the Python<->ObjC messaging 
bridge.   Anything specific to a particular framework should be 
elsewhere.

This will greatly contribute to supporting GnuStep.   As well, it makes 
it possible to use the bridge in contexts where one wants to use just 
the runtime, but none of the Foundation/AppKit classes -- 
Object/List/HashTable are still around and there are those [including 
me] who occasionally build new sets of classes that are not rooted at 
NSObject for research purposes.

None of this is to say that the extensions to the AppKit should not be 
separated out -- I have nothing against that, but I also am not 
strongly attracted to doing so.   In particular, part of the goal of 
the Foundation and AppKit modules is to provide seamless integration of 
the frameworks into Python -- this includes both mapping API [as does 
the various integration methods for NS* collections] and providing 
convenience functionality for working with the provided APIs.

b.bum