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

[Manuel Guesdon]

On Mon, 11 Feb 2002 16:08:48 +0000 (GMT) Nicola Pero <address@hidden> wrote:

 >| 
 >| >  >| So, for instance if object X is storing values in a dictionary, and 
 >| >  >| someone calls [X valueForKey: @"Y"]
 >| >  >| The class of X only needs to override -respondsToSelector: 
 >| >  >| methodSignatureForSelector: and forwardInvocation:
 >| >  >| so that when -valueForKey: tries to use -getY the value from the 
 >| >  >| dictionary is returned.
 >| > 
 >| > I think it doesn't work for this case:
 >| > An object X derived from EOGenericRecord which store values in dictionary.
 >| > X implements -getY which call [X storedValueForKey:@"Y"] (allowed by 
 >Apple)
 >| > In you proposition, EOGenericObject will return Y if it know it. But if 
 >it no, it will return A) nil or B) call
 >| [super
 >| > storedValueForKey:@"Y"].
 >| > In A) its' bad: X object may store Y as a real ivar (allowed by Apple)
 >| > in B) it's bad: the code will loop.
 >| > 
 >| > Don't forget that the object should look at real ivars before searching 
 >the dictionary.
 >| > 
 >| 
 >| I think I'm confused by this example, so let me rephrase it.
 >| 
 >| You want - 
 >| 
 >|  takeValue:forKey: to store stuff into ivars.  If an ivar is not found,
 >|  store it into a dictionary. (you do this by overriding
 >|  handleTakeValue:forUnboundKey:)

Yes.


 >|  valueForKey: to lookup the key in the ivars.  If none is found, to lookup
 >|  in the dictionary. (you do this by overriding
 >|  handleValueForUnboundKey:)

It's more complicated (see your next point).


 >| but then, you want to implement a 
 >| 
 >|  - getSpecialKey
 >|  - setSpecialKey: (id)value
 >| 
 >| method in the class, with the following implementation:
 >| 
 >|  - (id) getSpecialKey
 >|   {
 >|     return [self storedValueForKey: @"SpecialKey"];
 >|   }
 >| 
 >|  - setSpecialKey: (id)value
 >|   {
 >|     [self takeSoredValue: value  ForKey: @"SpecialKey"];
 >|   }
 >| 
 >| so your problem is that these methods would enter an infinite loop.

Yes, that's the problem. But it works with WO.


 >| I'm not sure why you need this implementation - the logic of the framework
 >| works in the reverse way - get/setSpecialKey should get/set the special
 >| key directly, in whatever way it's needed and appropriate for that key,
 >| but of course without using valueForKey:, because it's valueForKey: which
 >| should call them if they are available.

I may agree but as it works with Apple stuff, I think  it should work with 
GNUstep stuff.
Another point: I may define set<Key> only to log it's var but just want to use 
the default process after that. 


 >| So - the logical thing is that get/setSpecialKey should access the ivar if
 >| SpecialKey is an ivar, and the dictionary if it's a dictionary.

In WO. you don't have to know it it's an ivar or a dictionary key for this case.


 >| Say that you define your own lookup method - looking it up in this
 >| dictionary - 
 >| 
 >| - (id) valueFromDictionaryForKey: (id)key
 >| 
 >| then you implement
 >| 
 >| - (id) getSpecialKey
 >| {
 >|   return specialKey;
 >| }
 >| 
 >| if it's an ivar, and 
 >| 
 >| - (id) getSpecialKey
 >| {
 >|   return [self valueFromDictionaryForKey: key];
 >| }
 >| 
 >| if it's from the dictionary.  This is how it should be.

Dictionary is in EOGenericRecord and get/set value are in derived class. Except 
sometimes to do some special process,
the user which implement the derived class don't have to know if it's an ivar 
or not. BTW, EOGenericRecord has no API to
specialy get/set into dictionary.

The main point, IMHO, is to make things works like the reference API.

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