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