Re: GSEncodingName

[Richard Frith-Macdonald]

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?