Hello Markus, Marcus Müller schrieb:
> 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. I don't necessarily like #ifdef's as you mention there are some apps which expect set of semantics while others expect the other set, but there will generally be only one -base installed (per library combo). (This is why GDL2 replaces the implementations during +load) I'm also interested into which concrete version of KVC this is supposed to be compatible with. The reason I ask, is that if this matches WO45, I may consider implementing these semantics as categories in GDL2. Maybe we should create a micro KVCvX Framework/Library/Bundle that implements these categories when loaded without burdening -base. And I'd have GDL2 depend on that (or dynamically load that bundle though that might be too late for some cases). Cheers, David _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
