Re: [Pyobjc-dev] Separating functionality into modules

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

On Sunday, November 17, 2002, at 08:41 AM, Ronald Oussoren wrote:
> ...
> 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.

Right.  We are really talking about two things here;  the dependency on 
Foundation in objc's [current and likely forever] implementation and 
the presence of glue code used by the PyObjC developer when using the 
objc module.

The dependency isn't an issue -- it is purely a part of the current 
implementation and is not something that the developer need be aware of.

It is the access to the Foundation based functionality through the objc 
module that is problematic.  Specifically, it puts us in an 'all or 
none' situation and raises the question as to whether or not their is 
any value in the Foundation module at all;  should it be rolled into 
objc?

For a number of reasons, I don't think it should even if what remains 
is just a name.  In particular, you import the objc module if you want 
to use the ObjC runtime, you import Foundation to use the Foundation 
framework, etc...

It would seem to be a division that maps naturally to what is 
advertised through the rest of the system, both GnuStep and Apple's 
runtime.

You really *should* have to import the Foundation to work with the 
Foundation classes.

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

We should also strive to not require more implementation than is 
required to, say, use Object/HashTable/List, etc...

The reference counting APIs aren't strictly necessary in that context, 
nor should they be in the context of the PyObjC bridge.  If they aren't 
present, it is entirely up to the developer to invoke -free as required 
-- i.e. manage the object's lifespan entirely manually.

All in all, not something worth spending much time on at this point.

b.bum