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

[Nicola Pero]

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

Ok - so we agree it's better to remove them
 
> 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).

Storing key/values in dictionaries might be implemented as follows -

if you always want to store stuff in a dictionary, override
takeValue:forKey: to save the key/value in a dictionary, and valueForKey:
to read the value from the dictionary.

if you want to store stuff in a dictionary only if an ivar with that name
is not found, override handleTakeValue:forUnboundKey: to set the key/value
in the dictionary, and handleValueForUnboundKey: to return the value of
the key from the dictionary.

Other cases are managed similarly.

I'm not sure why you need to tell outside that something has some 'ivars'.  
To get a list of the valid keys for an object, I suppose that would be
done by asking for its NSClassDescription.  So - you would go by
subclassing NSClassDescription, and returning the appropriate attributes
(you subclass NSClassDescription to return different attributes, adding to
[super attributes]).  I'm not sure what the state of that is in gnustep.