Re: KeyValueCoding compatibility issues

[David Ayers]

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.

> 
>> I understand that -base intends to track Cocoa while GDL2 and GSWeb
>> aim at an ancient static API.  I could also instead transfer the
>> now missing methods to GDL2 but maybe we can work out a better
>> approach by extracting defined KVC API's into separate
>> Frameworks/Libraries/Bundles which can be linked/loaded by
>> applications that require them, rather than having -configure
>> decide for the entire GNUstep installation.
> 
> There aren't any missing methods as far as I know, and compatibility
> is determined by what your objects support at runtime, not by a
> configure.  But in any case I would have thought it made sense to
> gradually update to follow the Apple API changes in case you want to
> use GDL2 on MacOS.

I would love to see a way to gradually update the API while keeping
backward compatibility.  But my personal goal is keep GDL2 compatible
with WO45 as long as I need to support legacy installations.

If either:

- we can finally drop WO45 compatibility in our legacy code
- someone else wants to take over GDL2 maintiance and keep it up to par
with the current API on favor of compatibility for new apps (in which
case I could keep a personal branch).

I'd be glad to have GDL2 reworked.  In fact if i had API/design freedom,
I would have quite few changes I'd like to implement.

Cheers,
David