Re: KeyValueCoding compatibility issues

[Richard Frith-Macdonald]

On 2007-11-29 21:23:36 +0000 David Ayers <address@hidden> wrote:

> Richard Frith-Macdonald schrieb:
>> On 2007-11-29 17:24:55 +0000 Marcus Müller
>> <address@hidden> 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.

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 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.