I think it's a great idea!
On Feb 19, 2006, at 12:27 AM, Andrew Ruder wrote:
Hello all,
Objective-C is an incredible programming language, but right now the
most crippling factor for its widespread use is the lack of a
"standard
library." Right now there are two prevalent options to utilizing
Obj-C
in your program: GNUstep and OS X. Obviously the biggest problem with
OS X is that it is not free. GNUstep, however, brings along a whole
lot of other problems: crazy GNUstep/ directory structure, daemons,
config files, etc.. etc.. A typical developer not familiar with
GNUstep
sees these things and runs the other direction.
We are throwing away a tremendous opportunity here, you have lots of
developers who *could* be using a large chunk of GNUstep regardless if
they are not interested in the full GNUstep environment. Instead they
waste their time (no offense intended) on libFoundation and other such
OpenStep-like API implementations, because GNUstep is not flexible
enough for their needs. We can easily fill the role that
libFoundation
and derivatives are made to fill. Why is there any more than a single
free Foundation implementation being developed right now? In essence,
I'd like to propose that the -base library be split to fill this role.
Now, since you're still reading :) what I've discovered over the
course
of the last couple weeks is that *most* of GNUstep really is just an
object library. I started by separating out the following files:
NSConnection.m
NSDistantObject.m
NSDistributedLock.m
NSDistributedNotificationCenter.m
NSMessagePort.m
NSMessagePortNameServer.m
NSPortCoder.m
NSPort.m
NSPortMessage.m
NSPortNameServer.m
NSSocketPort.m
NSSocketPortNameServer.m
The distributed objects make GNUstep more than just an objects library
due to the additional overhead of the daemons. The only two files
besides these that didn't fit in the "just a library" paradigm were:
NSBundle.m
NSUserDefaults.m
Some parts of NSPathUtilities.m
Now, these were *especially* tricky to remove from -base since they
are
used everywhere. After spending some considerable time (and lots of
late nights ;)) I managed to get them removed in a manner that should
allow them to be re-added in a library on top of -base.
For the rest of this email I will refer to the eventual object library
made out of the remaining files (NSString, NSDictionary, etc..) as
"level1" and the above more-GNUstep-environment-centric files as
"level2"
The first change to level1 was to inventory exactly what it was
looking
up in defaults and from NSBundle to guage what exactly needed to be
abstracted. In the end, I decided the best implementation would be to
abstract all the uses into a GSDefaults class. The GSDefaults
class is
quite simple:
@interface GSDefaults : NSObject
[...]
/**
* Resource path for level 1 base
*/
- (NSString *)baseResourcePath;
/**
* Resource path for additions base
*/
- (NSString *)additionsResourcePath;
[...]
@end
Of course, there are additional methods to deal with the other
defaults
used throughout -base. After the split, the GSDefaults in level1
could
simply return the results obtained from ./configure, in level2 a
category would be created that could also obtain this information from
NSUserDefaults.
If anyone has any specific objections to any part of this proposal,
please reply with specific reasons why and how you think it could be
done better.
I'd like to begin work on -base by abstracting uses of NSBundle and
NSUserDefaults into an additional class. With NSBundle and
NSUserDefaults removed from most of -base, they can slide out into
another library. The distributed objects and associated daemons would
go with them or into an additional library. Also, it may be that
other
classes more properly belong in the environment-oriented library
(NSUndoManager, the formatters, etc.), but I believe NSBundle and
NSUserDefaults will be the most difficult and should be targeted
first.
As far as compilation against this reformulated -base, -make will
simply change what it is linking against. I would like to
eventually get
level1 to have the ability to compile with full FHS compliance
(/usr/lib, /usr/include, /usr/share, pkg-config for compiling/linking)
but that is only an issue after the split is made. After that I
will be
personally reviving as many of the obj-c bindings projects for various
libraries that I can find. Making obj-c a first class citizen on
linux
that plays nicely with a normal system setup = more eventual steppers
(the next logical step after discovering obj-c is the great use of
it by
-gui, imo).
Any thoughts? And as always, I will be willing to back up my
suggestions/etc. with the code/effort needed to implement it ;).
There
is of course interest in this kind of project, I think.
Cheers,
Andrew Ruder
And P.S., I really *do* have a *severely* hacked -base on my system
right now that I can link against and run programs with no environment
