> On 23 Sep 2016, at 20:08, Ivan Vučica <i...@vucica.net> wrote: > > If the equivalent functionality is exposed on the other implementation, I > don't see why not. > > If not, care should be taken for maintainability reasons. > > I also think it's perfectly fine to not expose functionality. Like on the > other implementation, if you decide to use a private interface and it breaks, > you get to keep the pieces.
Agreed ... gnustep-base has a policy of trying to expose the same APIs as Cocoa and move towards ever greater compatibility. So if Cocoa changes to expose new APIs, so should gnustep-base. However, it's not so much exposing equivalent functionality as attempting to expose identical functionality (we aim for compatibility). For extensions to the Cocoa APIs, we have the base-additions library, which is built in to gnustep-base but should build as a separate library on OSX, so that the extensions can be used in conjunction with Apple's Foundation framework. Where gnustep has historically had extension APIs in the standard Cocoa headers, the aim is to gradually remove them (either deprecating/deleting as they become really outdated, or moving them to the additions library if they are still useful). _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev