Re: Proposal: NSBundle frameworkWithName:

[Stefan Urbanek]

Hi David,

On 2003-08-13 19:44:00 +0200 David Ayers <address@hidden> wrote:

> Stefan Urbanek wrote:

<snip?

> > What do you think?
>
> Hi Stefan,
>
> I understand you're trying to push GNUstep into a new visionary era with the 
> "integrated environment" concept of yours.  It seems very intriging, but I'm 
> not sure the approach is correct.  Frameworks, as defined be the current FSF GCC 
> semantics and framworks as defines be Apple's tool chain semantics are already very 
> different.  I think we should focus in merging these semantics, rather than extending the 
> FSF GCC version.

:-)

I do not want to start different topic, so I will keep the original thread 
here. So read latter.

> If I understand you correctly it's a loadable bundle which exports headers.  
> User code should be able to import the headers and compile with them, without 
> having to link against it.  Maybe you should introduce a new name for it, as 
> this is different from what FSF GCC and Apple's tool chain thinks what 
> frameworks are.

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.

> A good start would be defining exactly how you think your "DynamicFramework" should work in light 
> of preprocessors finding headers, linking symbol resolution and dynamic loading.  My first guess is 
> "everything like Frameworks as Apple defines them but don't bail out when the framework is missing at 
> runtime and symbols references can't be resolved"... I guess you'll have to do a lot of GCC and ld 
> tweaking for that.  The second guess is, as loadable bundles but export headers.  This might be a more viable 
> aproach eventhough the things you are allowed to put in the exported headers are probably very limited.  My 
> guess would be protocols and catagories on classes known to all client apps and no classes specific to the 
> "DynamicFramework". But does that really justify a new bundle type?

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.

> I guess a developer can't compile a code using a "DynamicFramework" without it 
> being installed, but your approach seems to allow running it.  It also means, eventhough 
> I may never use StepTalk within ... lets take PC for example, I won't be able to compile 
> PC if it #included the StepTalk headers unless I also install StepTalk.

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.

> To do what you want now, all you really need is a stable protocol header, that each 
> "client" app would copy into thier source tree and use conventional loadable 
> bundles (aren't you doing that currently?).  This isn't really elegant but it serves the 
> purpose without introducing the complexity of yet another bundle type and it's 
> implications for the GCC tool chains.

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];
   }

This will trigger +instantiate method and framework can initialise itself. Even 
haders would not be necessary in such simple cases, if the framework just gives 
'categories'.

Besides that, with this functionality there will be very easy to have automatic 
loading categories in any object. Something like:

@implementation MyObject(FrameworkLoading)
- someMethod:blah
{
        /* Instead of [self notImplemented:_cmd] ... */
        return [self loadFramework:@"MyFramework" andPerformSelector:_cmd 
with:blah];
}
@end

The next time this metod is called, there will be Framework category installed 
and mentioned code will be replaced. The method 
loadFramework:andPerformSelector:with: should be implemented in some custom 
NSObject category, for example (not necesarily in GNUstep-base). This method 
replaces the functionality of GCC you have mentioned.

I just thought, that if there is similar functionality already implemented, 
that it can be made public. It was meant to be just a small patch for current 
situation.
Best regards,

Stefan