gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: en/decodeBase64 relocation


From: David Ayers
Subject: Re: RFC: en/decodeBase64 relocation
Date: Thu, 06 Dec 2007 16:12:30 +0100
User-agent: Mozilla Thunderbird 1.0.2 (X11/20070113)

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.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]