Re: GSEncodingName

[David Ayers]

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.)

>> Changing names could break
>> plists (such as EOModels) but that's probably not that bad as most  would
>> be using the common encodings which won't change.
> 
> 
> Well, if we change the names of the GNUstep specific enumeration 
> constants, that doesn't mean that gdl2 has to change the strings it 
> uses in the plists to match ... it could just leave them as the are,  or
> change to using string matching the new enumeration names. but  continue
> to recognize the old ones for backward compatibility.

OK, I've updated GDL2 to use the enumeration names.

[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.

Cheers,
David