[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GSEncodingName
From: |
David Ayers |
Subject: |
Re: GSEncodingName |
Date: |
Tue, 17 Oct 2006 09:36:02 +0200 |
User-agent: |
Mozilla Thunderbird 1.0.2 (X11/20060926) |
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
- Re: GSEncodingName, (continued)
- Re: GSEncodingName, David Wetzel, 2006/10/12
- Re: GSEncodingName, David Wetzel, 2006/10/12
- Re: GSEncodingName, Richard Frith-Macdonald, 2006/10/12
- Re: GSEncodingName, David Ayers, 2006/10/13
- Re: GSEncodingName, Richard Frith-Macdonald, 2006/10/13
- Re: GSEncodingName, David Ayers, 2006/10/13
- Re: GSEncodingName, Richard Frith-Macdonald, 2006/10/13
- Re: GSEncodingName, David Ayers, 2006/10/16
- Re: GSEncodingName, Richard Frith-Macdonald, 2006/10/16
- Re: GSEncodingName,
David Ayers <=
Re: GSEncodingName, David Wetzel, 2006/10/12