gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: KeyValueCoding compatibility issues


From: David Ayers
Subject: Re: KeyValueCoding compatibility issues
Date: Thu, 29 Nov 2007 22:23:36 +0100
User-agent: Mozilla Thunderbird 1.0.2 (X11/20070113)

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.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]