gnustep-dev
[Top][All Lists]
Advanced

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

Re[2]: Recent key-value encoding changes to NSObject.


From: Manuel Guesdon
Subject: Re[2]: Recent key-value encoding changes to NSObject.
Date: Mon, 11 Feb 2002 16:06:44 +0100 (CET)

On Mon, 11 Feb 2002 14:38:12 +0000 (GMT) Nicola Pero <address@hidden> wrote:
 >| I think you are not answering to Richard's point.  Richard is not against
 >| having KVC methods in core/base, or against improving the existing ones.  
 >| He is against that particular way of modifying them.
 >| 
 >| And I agree with Richard.
 >| 
 >| NSObject -handleQueryWithUnboundKey: raises an exception.  It is meant to
 >| be overridden in subclasses.  If in a subclass you want to do something
 >| else (than raising an exception), you override -handleQueryWithUnboundKey:
 >| to do whatever you want, then if what you want to do fails, you call
 >| [super handleQueryWithUnboundKey:].
 >| 
 >| I don't see why having an additional NSObject -_handleQueryWithUnboundKey:
 >| method would make things simpler.  You would then override
 >| _handleQueryWithUnboundKey: instead of handleQueryWithUnboundKey:.  Where
 >| is the advantage ?

_handleQueryWithUnboundKey: is only a part of the changes. I agree these 2 
methods aren't really necessary (I've just
added them to allow derived objects to handle these case hiddenly).

For the other changes (enable derived object to tell that it have some 
"ivars"). 
I don't agree. I think it should be in core IF KVC functions are in core. 
Without this, If we want to 
provide this feature, we have to copy all valueForKey:... methods in the 
derived object to just add 
an additional case handler. 



 >| To me, it looks like the existing public API should provide enough options
 >| to allow you do whatever key value coding you need.  I'm certainly against
 >| hacking the API and adding private hacks for unclear reasons.  If the
 >| public API is not enough powerful to implement the key value coding you
 >| need - which I strongly doubt - then we need to extend the public API (and
 >| as little as possible), /not/ add a private one.

EOGenericRecord and objects like that which want to have their values stored 
only in a dictionary or want to 
use a mixed (ivar/dictionary) storage method need a way to tell they have some 
"ivars".
Before doing this patch, I've tried to implement this without changing NSObject 
and without recoding the whole KVC stuff
but I haven't find a way to make this work to follow entirely apple's specs.
Apple's specifications and WO generated templates allow you to mix methods, 
ivars and dictionaries to store/retrieve
some values and I've found no other way to handle the case where values are 
mainly stored in dictionaries   (in EOGenericRecord
for example), with derived object storing only some values in ivars and 
implementing stored accessors which call 
storedValueKey: (as it is generated by WO templates).


Manuel

--
______________________________________________________________________
Manuel Guesdon - OXYMIUM <address@hidden>
14 rue Jean-Baptiste Clement  -  93200 Saint-Denis  -  France
Tel: +33 1 4940 0999  -  Fax: +33 1 4940 0998




reply via email to

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