Re: RFC: en/decodeBase64 relocation

[Tim McIntosh]

On Dec 6, 2007, at 9:54 AM, Richard Frith-Macdonald wrote:
> my current feeling is that the best approacch is to try to move  
> towards
> as completely compatible as we can with the main part of the base  
> library,
> and isolate the extensions etc in the Additions subproject.

Yes, yes, a thousand times yes.  ;)

> The reasoning behind this is that our best bet for encouraging Apple  
> developers to adopt GNUstep is by having them see good apps (such as  
> GNUMail) which work in both worlds, and the best way to encourage  
> ourselves to produce stuff that works on MacOS is to make sure that  
> everything (from the includes we need to use to the undocumented  
> behavior of individual methods) is as consistent between the two as  
> possible.

Amen.  It would certainly be a great help to people like me, who  
occasionally get the silly idea to waste their entire weekend trying  
to create Xcode projects to build GNUstep apps & non-core frameworks  
on top of Apple's Foundation/AppKit without GS Make (okay maybe I'm  
the only one stupid enough to attempt this ;).

One thing that recently bit me is that the OPENSTEP/MacOSX version  
numbers used in GSVersionMacros.h are incompatible/different than the  
same definitions on Mac OS X (e.g., MAC_OS_X_VERSION_10_2=100200 vs.  
1020 in Mac OS); when compiling GNUstep stuff under Xcode, I end up  
picking up the Apple definition of MAC_OS_X_VERSION_MAX_ALLOWED, for  
example, which was causing the OS_API_VERSION(ADD,REM) macro to  
produce unexpected results.  Modifying GSVersionMacros.h to use  
compatible version numbers solved the problem.

Another thing I noticed is that it looks like GNUstep is going to have  
big problems if you ever want to jump to ObjC 2.0, at least on top of  
the Apple runtime.  Deprecated methods in the Apple runtime seem to be  
used in lots of places.

> > But main issue is:
> > a) should we (continue to) add categories to standard classes
> > b) should we try to limit all future extensions to custom classes
> > I'm undecided leaning towards a) (at least until we have the first
> > collision with OS X).
>
> I'm fairly happy with categories (though the possibility of a  
> collision with MacOS-X methods of the same name does worry me a bit)  
> as well as new custom classes, but I'd like to see them in separate  
> header files so we have to explicitly include them and be more aware  
> that we are using extensions.  In theory, if we do that, then the  
> only thing we would need to do to port a program to MacOS-X is to  
> link it with the Additions library ... a single change to the  
> makefile.

I would also encourage people developing GNUstep applications to avoid  
using instance variables and private methods of (GNUstep) Foundation/ 
AppKit classes in application programs (why weren't the GS-specific  
instance variables declared @private, in the first place?), and  
instead add functionality to Additions, or find a portable way to do  
whatever needs to be done.  This seems to be a common practice in the  
GS applications I've seen, and it has thwarted virtually every attempt  
I've made over the last 10 years to port nontrivial GNUstep apps to  
Mac OS X.

That said, keep up the good work.

-Tim