Re: GSEncodingName

[David Ayers]

Richard Frith-Macdonald schrieb:
> 
> On 13 Oct 2006, at 06:17, David Ayers wrote:
> 
>> Thanks, I've just done this.  My main issue was not that it would be
>> hard to implement, it was a matter of maintaining the mapping together
>> with the NSStringEncoding enum.
> 
> 
> Ah ... that's part of the public API ... the name and value of the 
> NSStringEncoding enumerated type (NSString.h)
> 
> I can't see numeric values changing, but perhaps we should change the 
> non-standard enumeration constants to use a GS prefix rather than an  NS
> prefix.
> I expect we will also add character encodings in future, but  shouldn't
> remove any.
> 
> 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).

Changing numbers could break archives.  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.  Not following Cocoa's
enumeration could harm compatibility.

I feel weary to change anything without a good reason.  Even if we
change the names to the GS prefix we could clash with newer Cocoa values
and therefor breaking archives.

Possibly we should get some agreement with Cocoa developers on either a
seperate GNUstep namespace for enums and values or even a syncronized
enum.  (I've never tried contacting anyone about issues like this, but
maybe they would be responsive.)

Cheers,
David