[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: KeyValueCoding compatibility issues
From: |
Richard Frith-Macdonald |
Subject: |
Re: KeyValueCoding compatibility issues |
Date: |
Fri, 30 Nov 2007 06:01:40 +0000 |
User-agent: |
GNUMail (Version 1.2.0) |
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.
- KeyValueCoding compatibility issues, Marcus Müller, 2007/11/29
- Re: KeyValueCoding compatibility issues,
Richard Frith-Macdonald <=
- Re: KeyValueCoding compatibility issues, David Ayers, 2007/11/30
- Re: KeyValueCoding compatibility issues, Richard Frith-Macdonald, 2007/11/30
- Re: KeyValueCoding compatibility issues, Marcus Müller, 2007/11/30
- Message not available
- Re: KeyValueCoding compatibility issues, David Ayers, 2007/11/30
Re: KeyValueCoding compatibility issues, David Ayers, 2007/11/29