RFA: Reorganize GS extensions (was: RFC: en/decodeBase64 relocation)
Richard Frith-Macdonald schrieb: On 2007-12-06 15:12:30 + David Ayers [EMAIL PROTECTED] wrote: I've also added the declarations to the NSData.h header because -base avoids including GSCategories.h declarations when building itself and relies on the extensions being declared in GNUstep's standard headers. I it was once explained to me that this was done to avoid having folks who merely target GNUstep from having to include the special headers. I guess I'd forgotten this. But maybe we should reconsider this approach and remove the: /* The following ifndef prevents the categories declared in this file being * seen in GNUstep code. This is necessary because those category * declarations are also present in the header files for the corresponding * classes in GNUstep. The separate category declarations in this file * are only needed for software using the GNUstep Additions library * without the main GNUstep base library. */ #ifndef GNUSTEP in GSCategories.h Well, I think so. I don;t know who wrote that (it could well have been me), but my current feeling is that the best approacch is to try to move towards as completely compatible as we can with the main part of the base library, and isolate the extensions etc in the Additions subproject. Agreed... but it seems like quite a task (read can of worms)... - to consolidate all our NSObject.h/NSDebug.h/GC-related macros and provide the definitions that work for GNUstep (with/without GC) and OS X - find a solution for extensions like NSStringEncoding enum - find solutions for the implications wrt generating documentation I think this can only be done step by step and deal with the issues as the show themselves. My first proposal would be to start preparing the header files. I think seperate GSMacros.h file would be warrented. This file should contain at least all the macros currently defined in GSCategories.h. Then we need to decide which macros from NSObject.h and NSDebug.h should also be transfered or whether we should take the opportunuty to remove them. Attached is my first proposal: Cheers, David PS: I cannot test on OS X so I'll need some help testing... maybe someone can setup the autobuilder test for OS X. Index: ChangeLog === --- ChangeLog (Revision 25700) +++ ChangeLog (Arbeitskopie) @@ -1,3 +1,15 @@ +2007-12-08 David Ayers [EMAIL PROTECTED] + + * Headers/Additions/GNUstepBase/GSMacros.h: Copied + from GSCategories.h and removed references to + categories. + * Headers/Additions/GNUstepBase/GSCategories.h: + Include new GSMacros.h file and remove all + macro definitions. Move #ifndef GNUSTEP block + inside of other conditional block to allow extracting + definitions piece by piece. + * Source/GNUmakefile: Add new GSMacros.h file. + 2007-12-07 Richard Frith-Macdonald [EMAIL PROTECTED] * Headers/Additions/GNUstepBase/GSConfig.h.in: Index: Headers/Additions/GNUstepBase/GSMacros.h === --- Headers/Additions/GNUstepBase/GSMacros.h (Revision 25700) +++ Headers/Additions/GNUstepBase/GSMacros.h (Arbeitskopie) @@ -1,6 +1,6 @@ -/** Declaration of extension methods and functions for standard classes +/** Declaration of extension macros - Copyright (C) 2003 Free Software Foundation, Inc. + Copyright (C) 2007 Free Software Foundation, Inc. Written by: Richard Frith-Macdonald [EMAIL PROTECTED] and: Adam Fedor [EMAIL PROTECTED] @@ -22,23 +22,11 @@ Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02111 USA. - AutogsdocSource: Additions/GSCategories.m - */ -#ifndef INCLUDED_GS_CATEGORIES_H -#define INCLUDED_GS_CATEGORIES_H -#include GNUstepBase/GSVersionMacros.h +#ifndef INCLUDED_GS_MACROS_H +#define INCLUDED_GS_MACROS_H -/* The following ifndef prevents the categories declared in this file being - * seen in GNUstep code. This is necessary because those category - * declarations are also present in the header files for the corresponding - * classes in GNUstep. The separate category declarations in this file - * are only needed for software using the GNUstep Additions library - * without the main GNUstep base library. - */ -#ifndef GNUSTEP - #include string.h #include Foundation/Foundation.h @@ -59,6 +47,15 @@ @class NSMutableSet; +/* The following ifndef prevents the declarations in this section from being + * seen in GNUstep code. This is necessary because those + * declarations are also present in the header files for the corresponding + * classes in GNUstep. The separate declarations in this file + * are only needed for software using the GNUstep Additions library + * without the main GNUstep base library. + */ +#ifndef GNUSTEP + /* * Macros */ @@ -189,185 +186,15 @@ #define GS_INITIALIZED_LOCK(IDENT,CLASSNAME) \
Re: RFC: en/decodeBase64 relocation
On 2007-12-02 21:32:17 + David Ayers [EMAIL PROTECTED] wrote: Hello everyone, Even though base64 encoding is primarily used with MIME processing, its usage does spring up here in related and unrelated scenarios. It also seems more natural as an NSData category to me. I'm wondering whether this patch: moving the implementation of GSMime en/decodeBase64: to an NSData en/decodeBase64 category would be considered too much of a name pollution issue wrt NSData. I've had this patch in my tree for some time now (had to clean it up a bit and check for new usage of the current method so I cleanup some compiler warnings while I was at it to make sure I don't miss one). I agree that it seems natural as an NSData category, but I also think we need to avoid pollution of the basic headers/classes, so I don't think the patch is a good idea. IMO a more 'correct' patch would be to: 1. Put the implementation in Source/Additions/GSCategories.m (and the declaration in Headers/Additions/GNUstep/GSCategories.h) 2. Mark the methods in GSMime.h as deprecated and to be removed in version 1.17.0 3. Change GSMime.m and all files currently using the methods to use the NSData methods and include GSCategories.h ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: RFC: en/decodeBase64 relocation
Richard Frith-Macdonald schrieb: On 2007-12-02 21:32:17 + David Ayers [EMAIL PROTECTED] wrote: Hello everyone, Even though base64 encoding is primarily used with MIME processing, its usage does spring up here in related and unrelated scenarios. It also seems more natural as an NSData category to me. I'm wondering whether this patch: moving the implementation of GSMime en/decodeBase64: to an NSData en/decodeBase64 category would be considered too much of a name pollution issue wrt NSData. I've had this patch in my tree for some time now (had to clean it up a bit and check for new usage of the current method so I cleanup some compiler warnings while I was at it to make sure I don't miss one). I agree that it seems natural as an NSData category, but I also think we need to avoid pollution of the basic headers/classes, so I don't think the patch is a good idea. mhm... IMO a more 'correct' patch would be to: 1. Put the implementation in Source/Additions/GSCategories.m (and the declaration in Headers/Additions/GNUstep/GSCategories.h) 2. Mark the methods in GSMime.h as deprecated and to be removed in version 1.17.0 3. Change GSMime.m and all files currently using the methods to use the NSData methods and include GSCategories.h I'm a bit confused... or I should have explained it better but I thought the patch did these things... well almost. I've also added the declarations to the NSData.h header because -base avoids including GSCategories.h declarations when building itself and relies on the extensions being declared in GNUstep's standard headers. I it was once explained to me that this was done to avoid having folks who merely target GNUstep from having to include the special headers. But maybe we should reconsider this approach and change remove the: /* The following ifndef prevents the categories declared in this file being * seen in GNUstep code. This is necessary because those category * declarations are also present in the header files for the corresponding * classes in GNUstep. The separate category declarations in this file * are only needed for software using the GNUstep Additions library * without the main GNUstep base library. */ #ifndef GNUSTEP in GSCategories.h But maybe you just mean that the method of deprecation isn't optimal. What I did is that I simply removed the old method declaration from the GSMime.h header but left the implementation which produces a warning when invoked before forwarding it to the NSData category. The warning also doesn't specify a specific version of when the implementation would be removed. But main issue is: a) should we (continue to) add categories to standard classes b) should we try to limit all future extensions to custom classes I'm undecided leaning towards a) (at least until we have the first collision with OS X). Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: RFC: en/decodeBase64 relocation
On 2007-12-06 15:12:30 + David Ayers [EMAIL PROTECTED] wrote: Richard Frith-Macdonald schrieb: On 2007-12-02 21:32:17 + David Ayers [EMAIL PROTECTED] wrote: Hello everyone, Even though base64 encoding is primarily used with MIME processing, its usage does spring up here in related and unrelated scenarios. It also seems more natural as an NSData category to me. I'm wondering whether this patch: moving the implementation of GSMime en/decodeBase64: to an NSData en/decodeBase64 category would be considered too much of a name pollution issue wrt NSData. I've had this patch in my tree for some time now (had to clean it up a bit and check for new usage of the current method so I cleanup some compiler warnings while I was at it to make sure I don't miss one). I agree that it seems natural as an NSData category, but I also think we need to avoid pollution of the basic headers/classes, so I don't think the patch is a good idea. mhm... IMO a more 'correct' patch would be to: 1. Put the implementation in Source/Additions/GSCategories.m (and the declaration in Headers/Additions/GNUstep/GSCategories.h) 2. Mark the methods in GSMime.h as deprecated and to be removed in version 1.17.0 3. Change GSMime.m and all files currently using the methods to use the NSData methods and include GSCategories.h I'm a bit confused... or I should have explained it better but I thought the patch did these things... well almost. Probably I failed to follow what was going on well enough. I've also added the declarations to the NSData.h header because -base avoids including GSCategories.h declarations when building itself and relies on the extensions being declared in GNUstep's standard headers. I it was once explained to me that this was done to avoid having folks who merely target GNUstep from having to include the special headers. I guess I'd forgotten this. But maybe we should reconsider this approach and change remove the: /* The following ifndef prevents the categories declared in this file being * seen in GNUstep code. This is necessary because those category * declarations are also present in the header files for the corresponding * classes in GNUstep. The separate category declarations in this file * are only needed for software using the GNUstep Additions library * without the main GNUstep base library. */ #ifndef GNUSTEP in GSCategories.h Well, I think so. I don;t know who wrote that (it could well have been me), but my current feeling is that the best approacch is to try to move towards as completely compatible as we can with the main part of the base library, and isolate the extensions etc in the Additions subproject. The reasoning behind this is that our best bet for encouraging Apple developers to adopt GNUstep is by having them see good apps (such as GNUMail) which work in both worlds, and the best way to encourage ourselves to produce stuff that works on MacOS is to make sure that everything (from the includes we need to use to the undocumented behavior of individual methods) is as consistent between the two as possible. But maybe you just mean that the method of deprecation isn't optimal. What I did is that I simply removed the old method declaration from the GSMime.h header but left the implementation which produces a warning when invoked before forwarding it to the NSData category. The warning also doesn't specify a specific version of when the implementation would be removed. Yes, I was meaning that the use of the GS_API_VERSION macro in the header would produce the appropriate information in the auto-generated documentation (in addition to the runtime warning). But main issue is: a) should we (continue to) add categories to standard classes b) should we try to limit all future extensions to custom classes I'm undecided leaning towards a) (at least until we have the first collision with OS X). I'm fairly happy with categories (though the possibility of a collision with MacOS-X methods of the same name does worry me a bit) as well as new custom classes, but I'd like to see them in separate header files so we have to explicitly include them and be more aware that we are using extensions. In theory, if we do that, then the only thing we would need to do to port a program to MacOS-X is to link it with the Additions library ... a single change to the makefile. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
