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

[Manuel Guesdon]

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.


 >| >         - AFAIK, KVC is not used in core or GUI part.
 >| >         - today it's only used in EOF but it could be used elsewhere to 
 >| > add support for ivar like storing mechanisms
 >| > (use of dictionaries, for example) or specific optimizations (hasing 
 >| > the ivar names for example).
 >| 
 >| I wasn't talking about removing key-value coding support ... just about 
 >| sticking to the (as far as I can see
 >| perfectly adequate) MacOS-X API rather than adding extra unnecessary 
 >| methods.

I'm nearly sure MacOS-X duplicate the code or use hidden API or some hack to do 
this. I don't see another way to explain
the comportement of some objects and how WO generate some code for some 
Entreprise objects.

 >| 
 >| >         - EOF specifications don't say you have to derive your objects 
 >| > from EOGenericRecord and it
 >| > could be nice to have a minimum coding to make objects storing things 
 >| > in dictionaries or something else without
 >| > having to rewrite the whole KVC functions
 >| 
 >| But the whole point of the KVC stuff is that objects just need to 
 >| implement set/get methods to do this stuff,
 >| or in the case where the possible keys aren't known at compile time 
 >| (like fetching from a dictionary) overrides
 >| a few standard methods.  I don't see how the additional methods can make 
 >| things any simpler.  In fact, I'd
 >| argue that by making the API larger they actually make things more 
 >| complex.

Except the 2 _unbound... methods, the only change I've made it to provide a way 
for derived object to tell they have
some "values" not directly stored as ivars. Accessor is not the way to do this 
(see my mail to Nicola) because it
doesn't handle all cases.


 >| 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 may be wrong but all the studies I've made make me things that the only way 
is a possibility for 
derived objects to "announce" kind of ivars.


 >| >         - I think Apple has the same kind of 'hack'
 >| 
 >| If true, that's not really a justification.

Not a justification but if it seems to me that this is the only way to provide 
the same possibility as MacOS X/WO does
(at least, I've worked 2 days without finding a better one, except duplicate 
the code).

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