[Top][All Lists]

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

Re: KeyValueCoding compatibility issues

From: Richard Frith-Macdonald
Subject: Re: KeyValueCoding compatibility issues
Date: Fri, 30 Nov 2007 07:14:11 +0000
User-agent: GNUMail (Version 1.2.0)

On 2007-11-30 07:03:46 +0000 David Ayers <address@hidden> wrote:

Richard Frith-Macdonald schrieb:

No, I guess you misunderstood what Marcus was saying about the
define. What he did was to bracket the backward compatibility code
with the define, so that we can easily remove backward compatibility
at some future date if we want to.  The current code (ie with
backward compatibility turned on) checks at runtime to see what
methods the receiver responds to ... if the receiver responds to the
methods of the old API, the code behaves one way, if it responds to
methods of the new API it behaves the other way. This means that GDL2
ought to continue to work without modification, until we decide we
want to change it.

I missed the fact that backward compatibility was turned on by default.

But I don't understand how the runtime check

   static IMP    o = 0;

   /* Backward compatibility hack */
   if (o == 0)
       o = [NSObject instanceMethodForSelector:
   if ([self methodForSelector: @selector(takeValue:forKey:)] != o)
       [self takeValue: anObject forKey: aKey];

is supposed to work.  The objects generally /rely/ on KVC, they don't
override the primitives. Generally they implement the accessor methods (with or without underscore / 'get') or use one of the ivar conventions.

My understanding is that the backward compatibility already built in to the KVC code handled the normal cases where code merely uses the functionality built in to NSObject, or are you saying that GDL2 has been unable to use the base library since the new API was introduced in early 2005?

Marcus's additions should cope with the case where new and old KVC methods are overridden differently in different classes.

reply via email to

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