On 2007-11-30 07:03:46 +0000 David Ayers <[EMAIL PROTECTED]> 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
#ifdef WANT_DEPRECATED_KVC_COMPAT
static IMP o = 0;
/* Backward compatibility hack */
if (o == 0)
{
o = [NSObject instanceMethodForSelector:
@selector(takeValue:forKey:)];
}
if ([self methodForSelector: @selector(takeValue:forKey:)] != o)
{
[self takeValue: anObject forKey: aKey];
return;
}
#endif
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.
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev