On 16 Oct 2006, at 18:12, David Ayers wrote:
Richard Frith-Macdonald schrieb:
On 13 Oct 2006, at 07:25, David Ayers wrote:
Richard Frith-Macdonald schrieb:
As part of the public API, any removal/renaming will go through a
deprecation process ... I have tried to do a two release cycle
in the
past (ie if it's marked as deprecated in release N, then it
must still
be present in N+1 but we can remove it so that it is not in
release
N+2).
I'd like to make that standing policy for public API removal
(and I'd
like to get to a stage where private APIs really are private ...
not
exposed at all beyond the technical minimum of a few external
symbols
found in the binaries).
I'm a bit weary of the "technical minimum" approach since it seems
there
are at least some of us who started to rely on the documented API
(without necessarily consulting the headers), but I'll stick to the
sidelines until I have something more concrete.
(I hope you're not considering removing md5Digest or
hexadecimalRepresentation.)
What I want to get to is a situation where we are very clear what are
public extensions and what are internal APIs.
With the public extensions in the additions library rather than in
the main base library.
Extension macros/functions limited to a small number of well defined
groups (not random odd functions).
Extension methods in clear categories/classes in the additions library.
All clearly documented.
I'd only want to remove (after deprecation) stuff that practically
nobody uses ... on the theory that if hardly anyone uses it, it
should be in a separate library linked only by those people.
I only asked about the GC classes because my impression is that they
are pretty much unused, and they could easily be put in their own
library (and other GC collections added to it if anyone was interested).
[snip]
However, I don't want to change anything here until/unless we are
confident about doing the right thing.
Indeed! So let me take a little more time to express myself more
clearly.
When I say "name space" I actually meant a reserved range. But in
fact
that would mean we would already have to change the codes to achieve
that, which should be avoided.
One concern is of course that we enumerate in range that Apple will
use
for different encodings. Another concern is that we may introduce
encodings that Apple may introduce in the future with differing
values,
breaking compatibility in certain scenarios.
So what I'm trying to say is that these new encodings shouldn't be
handled as GNUstep specific "extensions" /if/ we can avoid it, by
requesting Apple's Cocoa developers to reserve the new values in their
headers. Now I realize that they may very well not care. It just
seems
that we could simply ask.
That sounds eminently sensible to me ... any idea who to ask?
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
