[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC: en/decodeBase64 relocation
From: |
Tim McIntosh |
Subject: |
Re: RFC: en/decodeBase64 relocation |
Date: |
Thu, 6 Dec 2007 22:13:08 -0600 |
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