Re: RFC: [GDL2/base] unableToSetNullForKey: / unableToSetNilForKey:

[Richard Frith-Macdonald]

On Monday, March 24, 2003, at 12:12  pm, David Ayers wrote:

> Hello...
>
> I'm stuck in a "little" ObjC runtime dilema.  I know that if mutiple 
> implementations of categories exists, that the choice of 
> implementation is undefined.  I was wondering if someone could nudge 
> me in the right direction on  handeling this while trying to follow OS 
> X and WO 4.5 API.
>
> Current gnustep-base and OS X Foundation call unableToSetNilForKey: 
> when takeValue:forKey: is invoked with NSNull/nil value on scalar key. 
>  EOF of WO4.5 should call unableToSetNullForKey:.  I was hoping to 
> find some way to override NSObject (NSKeyValueCoding) 
> unableToSetNilForKey: in GDL2 to invoke unableToSetNullForKey:.
>
> That way, if any base classes ever implemented unableToSetNilForKey: 
> there behavior would be unchanged.  But code implementing 
> unableToSetNullForKey: instead would  have a 2nd chance of handling 
> the situation before GDL2 NSObject (EOKeyValueCoding) 
> unableToSetNullForKey: would raise the coresponding exception.
>
> Now on the one hand we might be able to add a hook in gnustep base 
> that would allow "a second chance" selector to be invoked in 
> unableToSetNilForKey: but then this would only work for GDL2 when 
> compiled with base and not with OS X.
>
> I thought we reimplemented KVC in GDL2 to check if the reciever 
> responds to unableToSetNullForKey: in GSObjCSetValue before calling 
> unableToSetNilForKey: but that won't work either.  If we can't 
> override unableToSetNilForKey: for NSObject, then we won't be able to 
> override takeValue:forKey: either.
>
> How can we invoke unableToSetNullForKey: on OS X if 
> unableToSetNilForKey: of NSObject is invoked?

It's an ugly situation ... the lack of a way of controlling the order 
in which methods with the same name in different categories are used is 
a basic flaw in the idea of categories (so much so that some people 
just don't like to use categories at all).

The only way I know of to work around it is to mess with the runtime.
Fortunately we have a fairly well defined way of doing this with the 
use of behaviors (which could be viewed as categories added under 
runtime control rather than loader control).

You could create a class (called NilToNull for instance) which 
implements unableToSetNilForKey: by calling unableToSetNullForKey:, and 
use a call to
GSObjCAddClassBehavior([NSObject class], [NilToNul class]) to add that 
method to NSObject.

Of course, you would have to be careful to make this call *after* 
loading any bundles which might contain categories containing the 
method.