Re: EOKeyValueCoding

[Richard Frith-Macdonald]

On Sunday, February 24, 2002, at 03:16 PM, Manuel Guesdon wrote:

> On Sun, 24 Feb 2002 15:46:24 +0100 David Wetzel <address@hidden> 
> wrote:
> > | The problem we had is fixed with the code you send me. Thanks.
> > | Do you really think EOKeyValueCoding should be in EOF? I think it 
> > should be in the base lib.
> > |
> > | Why? Imaginge someone wants GSWeb programs without EOF.
> > | Or tools without GSWeb...
>
> There's a discussion about this on gnustep-dev mailing-list.
> I'd wanted to avoid to have KV implementations parts in too much 
> libraries (one part in base, some additions in GSWeb, some
> others in EOF,...). I thing it's better to have all additions related 
> to base objects (NSObject, NSArray, NSDictionary) in
> one place (_with_ all the needed handlers to enable derived objects 
> customization and minimize code+possible bugs in
> these customizations) and put specific (EOF, GNUstepWeb,... related) 
> parts in there own libraries.
>
>
> I was thinking about GNUstep additions and MacOSX portage. May be it 
> could be better to put all 'base' GNUstep additions in a separate 
> library
> (not in base, not in gsweb, not in EOF, not in extensions) so we have a 
> base which have same features as MacOsX and
> people who want to use GNUstep additions for GNUstep and/or MacOSX 
> applications can use this library. As you say, it
> could be a good place to  put some code so GNUstepWeb and others may 
> work without EOF.
>
> Anyway, I'm not maintainer of core so I let concerned people choose. 
> I'd just like to know the final decision soon so I can finish
> modifying GNUstepWeb and gdl2 for these points.

I think we have a very simple rule for where to put apple stuff ... 
maintain compatibility with apple.
If we put code in the wrong places, so it's either in the wrong headers 
or linked in as part of the
wrong frameworks (as far as apple compatibility is concerned), then we 
are making extra work for anyone
porting the code, and any end users could resonably report it as a bug 
and ask us to fix it.

A problem then only arises where apple have abandoned an API, but we 
want to keep it ... in which case
I think we should probably aim to keep it where they had it.

I don't want to put every API apple drop into the base and gui 
libraries ... that would just result in
bloated libraries with lots of APIs that most people don't want.  In 
fact, far from adding to the base
library, I'd rather try to factor out some GNUstep code (MIME, XML, SSL) 
into separate bundles
(or something similar) included as part of the base package but capable 
of being used independently.

I think this means the basic KVC stuff should be in the base library, 
with webobjects extensions in gsweb
and eof extensions in gdl2.

That being said, since I'm still not sure of the status of gdl2, it may 
be that some of the stuff from
there has nowhere to go but the base library.