Re: RFC: en/decodeBase64 relocation

[Richard Frith-Macdonald]

On 2007-12-06 15:12:30 +0000 David Ayers <address@hidden> wrote:

> Richard Frith-Macdonald schrieb:
> > On 2007-12-02 21:32:17 +0000 David Ayers <address@hidden> 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.