Re: [Pyobjc-dev] Separating functionality into modules

[Ronald O. <ous...@ci...>]

On Sunday, Nov 17, 2002, at 01:30 Europe/Amsterdam, bb...@ma... wrote:

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

It's missing documentation time again :-) :-). The glue code is where 
it is because you currently cannot avoid linking the PyObjC module with 
at least Foundation. This means that 
'objc.lookup_class("NSSomeFoundationClass")' will always work and 
therefore the glue must be loaded in objc.__init__.

I agree that users should avoid depending on this feature, if we at 
some point in time find a way to remove all dependencies on Foundation 
you will have to import Foundation to get access to those classes.

We currently use the following classes in the native code:
- NSMethodSignature, NSInvocation
   Used for calling Objective-C methods and required to fully support the
   reflection/invocation APIs for Python classes
- NSString, NSNumber
   used to automaticly convert strings and numbers from a python to an
   objective-c representation.
- NSException
   used for raising and catching Objective-C exceptions
- NSAutoreleasePool
   we allocate one when the module is loaded to avoid leaking objects 
(and
   generating tons of warnings until the user has created one)
- NSThread
   not used at the moment, but it will probably be necessary to use this
   class for fully supporting multithreading. We might get away with 
using
   the posix-threads API to store/create thread-local variables.

We also know about the existence of NSProxy because you shoudn't call a 
number of methods on it that we normally use. Given the list above I 
think it is quite unlikely that we'll ever be able to get rid of our 
dependencies on Foundation but you never know.

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

GNUstep aims to implement the entire OpenStep API, and their Foundation 
support seems to be production-quality. The most problematic part of 
supporting GNUstep will probably not be their class library, but the 
differences between the GNU and NeXT/Apple Objective-C runtimes. PyObjC 
0.6 contained and abstraction layer to deal with most differences. This 
layer is still present, but I've probably broken it during my rewrite.

And with respect to building classtrees that are not rooted at 
NSObject/NSProxy: We need to document what part of the NSObject API 
must be implemented if you want to use PyObjC to wrap those classes. 
This includes the reference counting API's, but there's probably more.

I'm not entirely sure about the right location for NibLoader, but I 
think the current location as part of the AppKit package is a logical 
location.

Ronald