Re: XML idea

[Kazunobu Kuriyama]

Alex Perez wrote:

> On Jan 8, 2004, at 5:06 PM, Kazunobu Kuriyama wrote:
>
> >  GNUstep can go its own way.  Could you explain more why GNUstep
>
> Yes, it is of course free to do as it wishes.
>
> > shouldn't take such a hierarchy?  The subdirectory seems to help you
> > purge what you call craps.
>
> Well, for starters, many "mediocre" classes, such as NSToolbar, also 
> make changes to other classes. I dont really see the point of putting 
> Cocoa classes which GNUstep has decided to implement in a separate 
> place, I guess. Added complexity, no gain. 

How about introducing new compilation switches to GNUstep?, as suggested 
by Fred Kiefer:

<quote>

> What I would like to see here is a bit of configuration for the 
> GNUstep libraries. If there is an OpenStep purist, he/she should be 
> able to compile GNUstep base and gui with as mininal extensions to the 
> OpenStep specification as possible (Here I mean a bit more than the 
> current usage of STRICT_OPENSTEP). And a Cocoa aficionado could set 
> another switch to get as much support as possible. The rest of us 
> "moderates" would of course get the best of two worlds. But here I 
> realize, I must be dreaming.

<end of quote>

We could define _OPENSTEP_SOURCE, _GNUSTEP_EXTENSIONS, _X102_SOURCE, 
_X103_SOURCE and so on for application
programs and __USE_OPENSTEP, __USE_GNUSTEP_EXTENSIONS, ... for internal 
use of library's source code (Yes,
I think of something like features.h of glibc).  And the configure 
script's hypothetical switch
--with-PortabilityKit enables some of them, say __USE_OPENSTEP_SOURCE, 
when -base/-gui is built, so that
NSWindow and so on won't be polluted by wrong part of NSToolbar and 
other classes you think "mediocre".

Hopefully, these hypothetical macros make the source code itself 
well-documented and could be
used for automatically generating document, which was suggested by 
Ricard Frith-Macdonald.

- Kazunobu Kuriyama