Re: GSEncodingName

[David Ayers]

Richard Frith-Macdonald schrieb:
> 
> 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.

Well I guess it all depends on what you consider a random odd function
as opposed to a useful extension.  And in the case of GSEncodingName I
think it was filling in a missing feature and it  was part of the
additions API. ...but that's history now... :-)

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

I have less of an issue with the request of removing GC collections.
Let's ignore the fact that removing the GC collections from GDL2 was
something I had in mind anyway.  I think there is nothing inherent about
them that they couldn't be part of a separate support library even if we
would have needed them in GDL2.  In the case of GSEncodingName, I do see
an inherent relation to the enum maintained in -base.  But like I said,
I currently do not have an outstanding concrete issue.

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

I would ask: address@hidden since this list was
created to coordinate Apple-GNU ObjC runtime coordination.  Even though
this is Cocoa issue I'm certain they can at least point to the right
place to ask.

Cheers,
David

[*]http://lists.apple.com/mailman/listinfo/objc-language