[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC] Header organization of -base & -gui
From: |
Richard Frith-Macdonald |
Subject: |
Re: [RFC] Header organization of -base & -gui |
Date: |
Thu, 3 Jul 2003 10:54:03 +0100 |
On Thursday, July 3, 2003, at 10:23 am, David Ayers wrote:
Adam Fedor wrote:
Well, GNUstepBase (a.k.a gnustep/base) doesn't just contain baseadd
headers, it also contains private headers for the internal
implementation of base. It would be easy not to install these on
apple-apple-apple, or perhaps not install them at all on any
platform...
Thanks, yes, let me clarify my view on this. I really think the
headers should either be private to -base (and therefor exist in the
Source directory) or be part of additions. If for some reason we
can't or shouldn't provide some functionalitiy within the header on
apple-apple-apple, then this should be #ifdef'ed with an comment
explaining exactly why this is the case. (Or maybe even providing a
runtime error message with the message, if the feature is function or
method.) But I doubt this should be necessary.
I strongly agree with this ... I very much support moving private
headers away from anywhere that a developer might be tempted to use
them. I'm not sure that any of the existing odd private headers should
be in the additions though ... I think only headers declaring public
stuff in the additions source should be in the additions headers, and
we should be parsimonious about extending the additions APIs.
After first sighting of these headers, though I believe the goal
should be to have the following headers privat to -base:
DistributedObjects.h
objc-load.h
Definitely.
and the following files should be part of -baseadd:
preface.h
GSFileHandle.(h/m)
Do we really want to expose these? I'm not sure how feasible it is.
Certainly we would need quite different versions of the code to work
with the MacOS-X foundation.
GSLocal.(h/m)
I don't know about this ... is it worthwhile and portable to MacOS-X?
GSUnion.h
GSIArray.h
GSIMap.h
Yes, these were always intended to be public.
- Re: [RFC] Header organization of -base & -gui, (continued)
- Re: [RFC] Header organization of -base & -gui, Adam Fedor, 2003/07/01
- Re: [RFC] Header organization of -base & -gui, Markus Hitter, 2003/07/01
- Re: [RFC] Header organization of -base & -gui, David Ayers, 2003/07/02
- Re: [RFC] Header organization of -base & -gui, Nicola Pero, 2003/07/02
- Re: [RFC] Header organization of -base & -gui, David Ayers, 2003/07/02
- Re: [RFC] Header organization of -base & -gui, Adam Fedor, 2003/07/02
- Re: [RFC] Header organization of -base & -gui, Nicola Pero, 2003/07/02
- Re: [RFC] Header organization of -base & -gui, David Ayers, 2003/07/03
- Re: [RFC] Header organization of -base & -gui, Adam Fedor, 2003/07/02
- Re: [RFC] Header organization of -base & -gui, David Ayers, 2003/07/03
- Re: [RFC] Header organization of -base & -gui,
Richard Frith-Macdonald <=
- Re: [RFC] Header organization of -base & -gui, David Ayers, 2003/07/03
- Re: [RFC] Header organization of -base & -gui, Nicola Pero, 2003/07/03
- Re: [RFC] Header organization of -base & -gui, David Ayers, 2003/07/03
- Re: [RFC] Header organization of -base & -gui, Nicola Pero, 2003/07/03
- Re: [RFC] Header organization of -base & -gui, Nicola Pero, 2003/07/03
- Re: [RFC] Header organization of -base & -gui, David Ayers, 2003/07/03
- Re: [RFC] Header organization of -base & -gui, Adam Fedor, 2003/07/03
- Re: [RFC] Header organization of -base & -gui, David Ayers, 2003/07/04
- Re: [RFC] Header organization of -base & -gui, Adam Fedor, 2003/07/06
- Re: [RFC] Header organization of -base & -gui, David Ayers, 2003/07/06