[Top][All Lists]

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

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

From: Richard Frith-Macdonald
Subject: Re: RFC: [GDL2/base] unableToSetNullForKey: / unableToSetNilForKey:
Date: Mon, 24 Mar 2003 12:28:10 +0000

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


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.

reply via email to

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