Re: GSEncodingName

[Richard Frith-Macdonald]

On 13 Oct 2006, at 07:25, David Ayers wrote:

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

yes ... which is why I can't believe that Apple would do it.

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

> Not following Cocoa's
> enumeration could harm compatibility.

Sure ... we should only ever move toward further compatibility, not  
away.

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

Well, the 'good' reason is to make it clearer that some encodings are  
GNUstep extensions which are not supported by Cocoa.
Changing the prefix for those encodings makes no difference regarding  
clashes of the numeric values as we would not be changing the numeric  
values.

However ... maybe we should ... see below.

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

I don't see how we could usefully have another namespace for enums,  
because they are basically just integers ... but a synchronized enum  
makes sense.
Perhaps we could ask them ... but I have no idea who to talk to though.

Cocoa does provide NSProprietaryStringEncoding = 65536.
I *think* the idea is that Apple encoding values should be less than  
this value (their highest used value is 30), though I haven't found  
that stated explicitly anywhere. Applications would then add their  
own character encodings from NSProprietaryStringEncoding onwards.  Of  
course, that doesn't help if two separate proprietory frameworks both  
want to add character encodings ... they could clash in the range  
beyond NSProprietaryStringEncoding.

GNUstep has NSProprietaryStringEncoding = 31
I'm not sure, but I think the GNUstep one is an old value and apple  
changed their value upwards, and we should probably change to avoid  
conflict with their reserved range..

That then leaves the GNUstep extensions ... in the range 50-67 at  
present ...
We could leave them where they are, or shift them to use another range.

perhaps

GSReservedStringEncoding = 65536
then our character sets
then NSProprietaryStringEncoding = 70000

so any code depending on adding its own charactersets beyond   
NSProprietaryStringEncoding would not clash with GNUstep charactersets.

However, I don't want to change anything here until/unless we are  
confident about doing the right thing.