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 variables, config files, or GNUstep/* directory structure ;) -- Andrew Ruder <[EMAIL PROTECTED]> http://www.aeruder.net _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
