Hi David,
On Mon, 30 Jun 2003 18:06:01 +0200 David Ayers <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 14 rue Jean-Baptiste Clement - 93200 Saint-Denis - France Tel: +33 1 4940 0997 - Fax: +33 1 4940 0998 _______________________________________________ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
