Re: KeyValueCoding compatibility issues

[David Ayers]

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