|Subject:||RFC: [GDL2/base] unableToSetNullForKey: / unableToSetNilForKey:|
|Date:||Mon, 24 Mar 2003 13:12:19 +0100|
|User-agent:||Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030210|
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?
|[Prev in Thread]||Current Thread||[Next in Thread]|