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

[Richard Frith-Macdonald]

On Monday, February 11, 2002, at 03:25 PM, Manuel Guesdon wrote:

> On Mon, 11 Feb 2002 14:42:13 +0000 Richard Frith-Macdonald 
> <address@hidden> wrote:
> > | On Monday, February 11, 2002, at 01:50 PM, Manuel Guesdon wrote:
> > |
> > | > On Mon, 11 Feb 2002 09:45:33 +0000 Richard Frith-Macdonald
> > | > <address@hidden> wrote:
>
> > | Not sure I understand that ... how much code would be redundant?  I'd
> > | have thought that a subclass could call the
> > | superclass code if it was not wanting to perform special actions ... 
> > so
> > | there should be little/no redundancy.
>
> As far as I can see, all takeValueForKey:.. code should be duplicated 
> because we have no way to
> take the hand in it (may be my explanation to Nicola wil help to 
> understand some cases.

Example -

@implementation MyObject
- (id) takeValueForKey: (NSString*)aKey
{
  id result = [myDictionary objectForKey: aKey];

  if (result == nil)
    {
      result = [super takeValueForKey: aKey];
    }
  return result;
}
@end

Zero code duplication.
Works for MyObject and all subclasses.
What is wrong with this in the case you are concerened about?

> > | 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"].

No ... it will return whatever you want it to return depending on how 
you code it ... that's my point ...
you have great freedom to do this stuff.

You can override the take/valueForKey style methods to intercept 
requests before any other processing is done.
You can override things like respondsToSelector to intercept the attempt 
to access values using the accessors.
You can override the handle... methods to intercept at the last minute 
after the standard selector and direct
ivar accesses have been tried.

So before, within, or after the main processing, you can intercept 
things and return *anything* you want.

> Don't forget that the object should look at real ivars before searching 
> the dictionary.

In that case, overriding the handle... methods would seem to be what you 
want.

Example -

@implementation MyObject
- (id) handleQueryWithUnboundKey: (NSString*)aKey
{
  id result = [myDictionary objectForKey: aKey];

  if (result == nil)
    {
      result = [super handleQueryWithUnboundKey: aKey];
    }
  return result;
}
@end