EO/NSNull.m was:(Re: GDL2 patches (2))

[David Ayers]

David Ayers wrote:

> As most code #including the header will want EONull to implement the 
> methods, but we are internally using NSNull, the switch is done only 
> in the implementation file.  But maybe we should move the define 
> closer to the category implementation.  Or be explicit about it in the 
> implementation file and change the name in the implementation 
> definition.  Or maybe move the define to EONull.h.  

Actually I almost like this...

What if we reduce EONull.h to:

#ifndef __EONull_h__
#define __EONull_h__

#ifndef NeXT_Foundation_LIBRARY
#include <Foundation/NSNull.h>
#else
#include <Foundation/Foundation.h>
#endif

#define EONull NSNull

@interface EONull (EOSQLFormatting)
- (NSString *)sqlString;
@end


#endif /* __EONull_h__ */
(any maybe keep the convinence categories/functions...)

And EONull.m only implemented:
@implementation EONull (EOSQLFormatting)
- (NSString *)sqlString
{
 return @"NULL";
}
- (id)valueForKey:(NSString *)key /* Maybe base should implement this... 
Could someone test on OS X?*/
{
 return self;
}
@end

That way we should never have to worry about having 2 classes available 
and conflicting warnings for conflicting
- (EONull *)method;
and
- (NSNull *)method;

Yet this breaks NSClassFromString(@"EONull") (and therefore the guile 
tests :-( and probably other scripting frameworks).  So I'm not 
convinced yet.  I would want to avoid tricking both runtimes to return 
NSNull for objc_lookup_class/objc_lookUpClass with "EONull'.  But I 
guess that's what it would take.

Cheers,
Dave