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 _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev