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 _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev