Re: Proposal: NSBundle frameworkWithName:

[David Ayers]

Stefan Urbanek wrote:

> Hi David,

[snip]

> I do not think that it is something different than frameworks as we 
> know them. It is just different kind of use of them. Frameworks are 
> already bundles with interface (headers), and they can be loaded 
> dynamically too. 

Well, there's a lot more to frameworks than that :-).  For Apple 
semantics check:
http://developer.apple.com/documentation/MacOSX/Conceptual/SystemOverview/Frameworks
But yes they do define framework as *dynamic* shared libraries that 
delay symbol resolution until reference.  I thought it was during 
loading that the symbols are resolved, but I guess I was wrong.  And the 
comments in our NSBundle.m suggest that this should also work with FSF 
GCC.  (You learn something new everyday. :-) ) 

> Yes, if you like to have support in compiler. The interface i have 
> proposed does not require extra copiler support, because you do not 
> specify the framework name to the linked, but in the sources. Not GCC, 
> bnu GNUstep-base is responsible for finding that framework with given 
> name and return corresponding NSBundle. 

And you may not export any classes that should be subclassed.

> You are definitely true here. Now I understand, why you have mentioned 
> different kind of frameworks/bundles and extra gcc support. Is there 
> any easy way how this can be solved? AFAIK, using #import for 
> non-existant header is only a warning, in't it? But ignoring that can 
> cause troubles.

Well the projects using StepTalk could use configure to test if it's 
installed and use #ifdef to #include/#import or not.  But if they don't 
find the headers the signatures the compiler uses will most likely be 
incorrect.  So don't expect it to work with out recompiling if StepTalk 
is installed afterwards.

> Yes, I already provide protocol headers and some implementation files. 
> This solution is 'better than a nail in the eye'. I fine with it, but 
> I am not too satisfied. There are problems when I do updates to those 
> headers and this can be annoying to other develoeprs, because they 
> have find it out that such change happened and to download files again.
> For the time being, current solution is not too bad, but I am afraid, 
> that from the future point of view it is not very sufficient. This 
> small method for loading frameworks can at least eliminate 
> distribution of implementation files. Only code needed in 
> application/tool in most cases would be:
>
>    bundle = [NSBunde bundleForFramework:@"MyFramework"];
>    if([bundle load])
>    {
>        [[bundle principalClass] class];
>    }

Hmm. You have tried using bundleWithPath:, right? Ahh, but you want to 
search the "standard" frameworks paths.  So you would have to loop 
around NS/GSStandardFrameworkPaths() (which doesn't seem to exist but 
could be derived from NSStandardLibraryPaths) and your request would be 
implementing a GSStandardFramewoksPaths and also haveing a 
bundleForFramework: convinience method in NSBundle to do that searching 
... hmm.  I think I understand now, but I'll wait for Nicola to 
comment.  But it seems technically doable.

Cheers,
David