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

[Nicola Pero]

> I'll try to summarize the problems I've found and the reason why I've added 
> this in core/base.

thanks - this is useful

> Say X will have 2 values: a and b.
> o X will store A in an ivar (_a) the other is stored in EOGenericRecord in a 
> dictionary "_values".
>         _value is a special dictionary which know it's keys (including a even 
> if it won't store it itself in
> our case. There's a reason for this that I could explain if you want :-).
> 
> X will have the following methods:
>         -(id)a
>         {
>                 [self storedValueForKey:@"a"];
>         }
>         -(void)setA:(id)anA
>         {
>                 [self takeStoredValue:anA
>                         ForKey:@"a"];
>         }

As far as I understand, this implementation of X makes no sense.  If _a is
an ivar, this should be - 

- (id)a
{
   return _a;
}

- (void)setA: (id)anA
{
  ASSIGN (_a, anA);
}


>         -(id)b
>         {
>                 [self storedValueForKey:@"a"];
>         }
>         -(void)setB:(id)aB
>         {
>                 [self takeStoredValue:aB
>                         ForKey:@"b"];
>         }

And this should be 

- (id)b
{
  return [self whateverMethodToAccessThe_valueDictionary: @"a"];
}

- (id)setB: (id)aB
{
  return [self whateverMethodToAccessThe_valueDictionary: aB  forKey: "b"];
}


takeStoredValue:forKey: is implemented in terms of b and setB:, not vice
versa.  

Unless - ... - unless the Apple documentation is wrong, and when it says
that takeStoredValue:forKey: makes steps 2,3,1 and 4 - that might be
actually wrong, and it might make steps 2,3 and 4 - but not 1.  Then you
could define setA: in terms of takeStoredValue:forKey:, because
takeStoredValue:forKey: would simply not look for setA:.  This would make
a lot of sense, so if anyone has an apple system, could you please check
if takeStoredValue:forKey: does use set<Key>: (as opposed to _set<Key>:)
or not ?