Richard Frith-Macdonald schrieb: > On 2007-11-29 17:24:55 +0000 Marcus Müller > <[EMAIL PROTECTED]> wrote: >> >> KVC compatibility is badly broken in several situations, where >> subclasses usually override specific methods, but the calling API >> was partly ported to use the new-style KVC, i.e. >> -takeValue:forKey: is somehow mixed with -setValue:forKey:. >> Usually, this happens when you port an application to the new API >> but some underlying framework has yet to be ported... the result >> is something which doesn't work properly at all. >> >> Attached, find a patch that fixes all these problems. As an added >> bonus, all compatibility code is prepared for exclusion from >> compilation, making it very easy to actually migrate to the >> new-style KVC completely. All compatibility workarounds will then >> be excluded as well, making KVC a bit faster altogether. > > Great ... thanks very much ... I checked the patch over visually, ran > the testsuite on a copy of base with it applied, and comitted it to > svn.
Hmm, so I guess anyone needing GDL2 would have to set that define for -base. 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. That way apps can choose the semantics they want by linking/loading the compatibility code or not. Of course some apps (like GORM) will still face some rather volatile behavior when they start loading GDL2 code Palettes and therefor combine code expecting different semantics. Not really sure what the best course of action is... it may not be feasible to have GDL2/GSWeb rely on current -base anymore... Cheers, David _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev