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

[Richard Frith-Macdonald]

On Monday, February 11, 2002, at 03:06 PM, Manuel Guesdon wrote:
> 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.

I don't understand this argument.  Why would you need to copy the 
methods?

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

Overriding handleTakeValue:forUnboundKey: and handleQueryWithUnboundKey: 
would deal with that,
and I think I already convered how you can handle more complex cases and 
actually use standard
methods to intercept the KVC mechanism early on to do things more 
efficiently.

> 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).

I think we need concrete code examples ... from just what you have said 
I still can't see
what's wrong with using the methods already available in the standard 
API.  Indeed, for
the case you seem to be suggesting, the two -handle... methods alone 
would seem to be
sufficient (though not the most efficient implementation).