gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re[4]: KVC bug


From: Manuel Guesdon
Subject: Re[4]: KVC bug
Date: Wed, 27 Feb 2002 16:06:42 +0100 (CET)

On Wed, 27 Feb 2002 11:53:15 +0000 Richard Frith-Macdonald <address@hidden> 
wrote:

 >| 
 >| On Wednesday, February 27, 2002, at 11:19 AM, Manuel Guesdon wrote:
 >| >> | PS. Also implemented MacOS-X compatible KVC behavior in 
 >| >> NSDictionary.m
 >| >
 >| > It makes troubles for me. Please see the code I've sent and WO 
 >| > specifications at
 >| > 
 >http://developer.apple.com/techpubs/webobjects/Reference/Javadoc/com/webobjects/
 >| > foundation/NSDictionary.html
 >| > "allValues", "allKeys", and "count" are special cases.
 >| >
 >| > Could you make some  tests on MacOSX to see if your code is right or if 
 >| > mine is right (just adding an object for key
 >| > count and see what valueForKey:@"count" give you)  ?
 >| >
 >| > My code is:
 >| > @implementation NSDictionary (EOKeyValueCoding)
 >| >
 >| > - (id)valueForKey:(NSString *)key
 >| > {
 >| >   //OK
 >| >   id value;
 >| >   value = [self objectForKey:key];
 >| >   if (!value)
 >| >     {
 >| >       if ([key isEqualToString:@"allValues"])
 >| >         value=[self allValues];
 >| >       else if ([key isEqualToString:@"allKeys"])
 >| >         value=[self allKeys];
 >| >       else if ([key isEqualToString:@"count"])
 >| >         value=[NSNumber numberWithInt:[self count]];
 >| >     };
 >| >   return value;
 >| > }
 >| >
 >| >
 >| > If your code is right, we have a big problem: how could we have same 
 >| > foundation but 2 differents way of processing
 >| > depending on what we use (GNUstepWeb/EOF or not)
 >| 
 >| My code is correct ... but this should not be a problem.
 >| Your category implementation should 'trump' the implementation in 
 >| NSDictionary itsself.
 >| 
 >| So, if you build with just GNUstep-base, you get the Apple Foundation 
 >| behavior, and if you
 >| build with GNUstepWeb/EOF you get the Apple webobjects behavior.
 >| 
 >| Of course, we should test this - but methods in categories *should* 
 >| override the methods
 >| in the original class.

My god !

This really means that *just*  linking or not with EOF (explicitely or just 
because it's in the Makefile.preamble copied
from somewhere) will change the behaviour of valueForKey: for dictionary ? Or 
even different objective C library (I
don't know where/how the category override is done).
I think some people will have great moments trying to debug this. Let's imagine 
a general bundle or a library for computing some
stats, wich can be used with or without EOF. A thing as simple as 
valueForKey:@"count" may return a
different result. I imagine a discussion between a user of this bundle and the 
developper: 
- the user, I've fund some problem.
- the developper, could you provide me some small test code ?
- the user: here is one but, eh !,  now it seems to work
- the developper: could you rebuild your entire projects, it should work
- the user: this still don't work but the test code works...
....

I know the problem come initialy from Apple's API but couldn't we use my code 
and your code with a "Strict MacOSX API
compatible" #ifdef to select your code ? I generaly like compatibility but not 
if this potentially mean completely
strange problems and hours or days of debugging

Just for confirmation, you say your code is correct because you've made a test 
or because cacoa documentation say
nothing about these special keys ?

Manuel
PS: Sorry to come again on KVC, I know it's pretty boring for everyone :-)
--
______________________________________________________________________
Manuel Guesdon - OXYMIUM <address@hidden>
14 rue Jean-Baptiste Clement  -  93200 Saint-Denis  -  France
Tel: +33 1 4940 0999  -  Fax: +33 1 4940 0998




reply via email to

[Prev in Thread] Current Thread [Next in Thread]