[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Framework Classes
Re: Framework Classes
Mon, 20 Oct 2003 13:28:54 +0100 (BST)
> >> I do not know how to implement it, but AFAIK, there is some code that
> >> generates similar list in a source file. Would it be possible to reuse
> >> that
> >> code to generate one .plist?
> > If you can convince me that there is an advantage in having the .plist
> > file, maybe we should always generate the .plist file instead of putting
> > the list of classes in an automatically generated class. Instead of
> > reading the list of classes from the automatically generated class,
> > gnustep-base itself could read it from the .plist file.
> Well, if we already have a funcitonality in gnustep-make tha generates such
> then i think that the list should be provided as public. At this time it
> is private to gnustep libs, by providing it as public anyone can reuse
> the information.
> To be future compatible, the plist should be not just an array, but some
> At this time with just one key: 'Classes = (array)'.
I'm now thinking this could be a normal entry in the standard .plist
dictionary for that framework.
Of course then getting the list of classes in the framework depends on the
ability of locating the framework bundle on disk, which is one of the most
difficult areas in framework support. So we might be making listing the
class in a framework less reliable.
What I'm doing then is I'll add an entry to the standard .plist with the
list of classes, but I'll keep the list of classes in the object file as
= thinking =
Btw in this respect, I quite like the way Java does it, where you have a
single consistent way (the classpath) of finding/loading both classes and
resource files (I mean, you can look for class gnu.gnustep.base.NSObject;
or for resource file gnu.gnustep.base.NSObjectAttributes; and they will be
looked up using the same mechanism; now if you imagine "gnu.gnustep.base."
is the equivalent of a framework [a self-contained directory containing
both classes and resources] you see that because they load classes and
resources in the same way, a "framework" is trivially implemented); unix
doesn't have that, because there is a special separate way of loading
libraries / object files, used by the linker, but you can't load resources
in that same way. An ugly workaround might be to compile all resources
into object files and then load them using the linker.
Maybe we should implement a java-like way of locating both object files
and resources, and then embed our frameworks into that. The main problem
is that the linker normally doesn't do that.
I suppose it would be great would be to have the linker do the following -
- have a search path (user configurable). Say it is the existing
- be able to locate stuff in the search path not only by name, but by
relative path. At the moment you can only look for libRenaissance.so in
the search path, for example - it would be a lot more flexible if you
could search for 'GNUstep/AppKit/libMyBackend.so' for example - that would
iterate on the search path, and for each path, append
'/GNUstep/AppKit/libMyBackend.so', and search for that file.
- be able to call the dynamic linker programmatically, asking it to
locate a file using its standard search path based search. The file does
not have to be an object file, and again you'd be able to use a relative
If we had those two features, implementing frameworks would be very easy.
They would likely be very useful generally for unix libraries, as you
could then have a well organized /usr/lib directory with proper
subdirectories (rather than a messy directory with a million files in it);
and unix libraries could store resources (images, etc) in the same
directory used for the library itself, and find them easily. Eg,
then you do -lmylibrary/mylibrary and at runtime you can look for file
'mylibrary/image1.gif' and that will be located using the same search path
used to locate the library. I assume ld.so.cache would only record .so
files, and not resource files. Then it would be not much bigger than it