[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re[6]: EOKeyValueCoding
From: |
Richard Frith-Macdonald |
Subject: |
Re: Re[6]: EOKeyValueCoding |
Date: |
Sun, 24 Feb 2002 21:14:56 +0000 |
On Sunday, February 24, 2002, at 08:38 PM, Philippe C.D. Robert wrote:
On Sun, 24 Feb 2002 21:04:31 +0100 (CET)
Manuel Guesdon <address@hidden> wrote:
| >> | This isn't an issue any more. We should place a KVC
implementation in
| >> | FoundationExt if we want to support deprecated OS's like
OPENSTEP.
| >> | Indeed because KVC is part of Foundation it's much easier now,
since
| >> you
| >> | don't need to maintain runtime specific code in GDL :-)
| >
| > I agree :-) on the last sentence but in this case, why putting
"base
| > KVC" in FoundationExt an not base ?
|
| As I wrote, to support old Foundations which do *not* have KVC in
| Foundation (like the Foundation of OPENSTEP). I would *copy* the
code
| over to FoundationExt (so it's contained in both libraries).
You're right. I've forgotten this one.
IMHO this would be a bad move from our side. Of course old code should
be
supported whenever possible, but much, much more important is IMHO to
be and
remain compatible with Cocoa/Apple. We have to be very careful not to
introduce
incompatibilities on basic stuff like that.
Yes ... I think it's considerably more important to keep stuff like this
in
sync with MacOS-X than to support OPENSTEP. I imagine that the userbases
concerned differ by three or four orders of magnitude.
I think I said before, it would be reasonable to consider putting this
stuff in
another place than Apple do to simply be a bug - I'm pretty sure most
users
would look at it that way.
BTW who actually has FoundationExt installed who does not really use
GDL?
Another problem with that being that afaik FoundationExt is not part of
GNUstep
because it's never been given to the FSF ... so we don't want to add
GNUstep
code to it, or have GNUstep code depend on it (another reason why I'd
really
like to have a gdl2 without such a dependency).
- Re: EOKeyValueCoding, Manuel Guesdon, 2002/02/24
- Re: EOKeyValueCoding, Richard Frith-Macdonald, 2002/02/24
- Re[2]: EOKeyValueCoding, Manuel Guesdon, 2002/02/24
- Re: Re[2]: EOKeyValueCoding, Helge Hess, 2002/02/24
- Re[4]: EOKeyValueCoding, Manuel Guesdon, 2002/02/24
- Re: Re[4]: EOKeyValueCoding, Helge Hess, 2002/02/24
- Re[6]: EOKeyValueCoding, Manuel Guesdon, 2002/02/24
- Re: Re[6]: EOKeyValueCoding, Philippe C.D. Robert, 2002/02/24
- Re: Re[6]: EOKeyValueCoding,
Richard Frith-Macdonald <=
- Re: EOKeyValueCoding, Adam Fedor, 2002/02/24
- Re: EOKeyValueCoding, Nicola Pero, 2002/02/24
- Re[2]: EOKeyValueCoding, Manuel Guesdon, 2002/02/25
- Re: Re[2]: EOKeyValueCoding, Richard Frith-Macdonald, 2002/02/25
- Re[4]: EOKeyValueCoding, Manuel Guesdon, 2002/02/25
- Re: Re[4]: EOKeyValueCoding, Nicola Pero, 2002/02/25
- Re[6]: EOKeyValueCoding, Manuel Guesdon, 2002/02/25
- Re: Re[6]: EOKeyValueCoding, Nicola Pero, 2002/02/25
- Re: EOKeyValueCoding, Adam Fedor, 2002/02/25
- Re[2]: EOKeyValueCoding, Manuel Guesdon, 2002/02/26