Re: [RFA/gdl2] EOKeyValueCoding

[Manuel Guesdon]

Hi David,


On Mon, 30 Jun 2003 18:06:01 +0200 David Ayers <d.ayers@inode.at> wrote:
 >| I'd like your approval on this one.  This is my first cleanup of 
 >| EOKeyValueCoding.  I've been using this implementation more or less 
 >| since February, but I haven't consciously used some of GDL2 extensions 
 >| (well only in simple tests). What this does:
 >| 
 >| - Relies on -base/Foundation's implementation for all equivalent 
 >| implementations.
 >| - Replaces -base/Foundation's implementation of unableToSetNilForKey: to 
 >| call unableToSetNullForKey:
 >| - Optimizes NSArray computational implementations to use NSDecmial 
 >| structs instead of temporary NSDecimalNumber objects
 >| - Cleans up serveral implementations.
 >| - Adds documentation

Sounds great.


 >| I currently left the special handling of quoted keys in the NSDictionary 
 >| catagory, eventhough it can be turned off with the 
 >| GSUseStrictWO451Compatibility default.  I'm hoping to find time to 
 >| implement a GSWMutableDictionary to be used in the GSWDisplayGroup 
 >| sometime, so that we can move that handling there.

I've started this some time ago but abandonned it. Helas, I can't remember why 
:-(


 >| This shouldn't change (well only correct some edge cases) the current 
 >| behavior.  I have run simple tests on all the methods.  But I would like 
 >| you to test it against your app before I commit.
 >| 
 >| The following questions remain:
 >| -smartTakeValueForKey: seems to be hooks to support EOGenericRecord 
 >| which consults the relationship definitions to send the 
 >| add/removeObject:to/fromBothSidesOfRelationshipWithKey: messages instead 
 >| of takeValue:forKey: if applicable.  

Right.


 >| Why is this specific to 
 >| EOGenericRecord and not implemented for custom objects?

Good question :-) A (selfish) reason is that I base my records on 
EOGenericObject and don't use 'Custom Objects'
mechanism. As far as I remember, in previous versions of EOF, using 
EOGenericRecord as base object  
was not possible or it has bad side effects. I think it's no more a problem on 
WO 4.5 EOF so I haven't worked on
custome objects.


 >| -smartTakeValueForKey: is currently only used in 
 >| GSWBundle-initializeObject:fromArchive: and 
 >| GSWComponent-synchronizeParentToComponent and no where in GDL2 itself.  
 >| I'm wondering whether we really need it at all.

If we move the logic of it in takeValue:forKey:, yes, we no more need it. 
Originaly, I've written this method to avoid changing takeValueForKey: 
implementation even if I think it's really a
better way to do because with this developper don't have to explicitely take 
care of bidirectional relationships, he
just have to call smartXX method. When schema change, no code change is 
necessary.


 >| -smartTakeValueForKeyPath: is currently only used in 
 >| GSWAssociation-setValue:inObject:forKeyPath: and this already contiains 
 >| an alternative implementation when GDL2 isn't available.  I'd rather 
 >| move the logic to GSWAssociation and remove smartTakeValueForKeyPath:

Same thing, I use it in my code to avoid taking care of bidirectional 
relationships.

But anyway, I'm open to better solutions.


 >| I also have the feeling that we could do without 
 >| takeStoredValueForKeyPath: and storedValueForKeyPath:.  They both use 
 >| valueForKey recursively (and why not storedValueForKey?) until the get 
 >| to the object before the targeted object, and then send the 
 >| corresponding stored KVC message.  Yet these meothods are used neither 
 >| in GDL2 nor in GSWeb.
 >| valuesForKeyPaths: and storedValuesForKeyPaths:  are also seem unused 
 >| and I think we should also remove them.

I use them too and I think it make API consistent, IMHO.



 >| Again I've added the files instead of a diff to make reviewal easier.

Thnaks. I'll test this !

Manuel


--
______________________________________________________________________
Manuel Guesdon - ORANGE CONCEPT <mguesdon@orange-concept.com>
14 rue Jean-Baptiste Clement  -  93200 Saint-Denis  -  France
Tel: +33 1 4940 0997  -  Fax: +33 1 4940 0998