Re: GNUstep ROADMAP

[Richard Frith-Macdonald]

On 28 Nov 2005, at 02:17, Gregory John Casamento wrote:

> Fred,
>
> --- Fred Kiefer <address@hidden> wrote:

> > When I started with GNUstep, most of the
> > GUI classes where empty declarations, which needed filling out and  
> > that
> > was what I did.
>
> Having empty declarations is okay for something that's in beta,  
> however, for a
> 1.0, I'm not sure that we should include those classes which are  
> simply empty
> declarations.
>
> > If we would have removed all classes without
> > implementation at that time, GNUstep would still be rather empty.
> > I really would prefer warning messages at runtime from removing  
> > classes
> > as a whole. Will it be a problem that some applications will compile,
> > but later fail to run correctly? I don't think so, as long as we  
> > output
> > honest warnings about missing code.
> >
> > Having a method not implemented
> > macro in some GNUstep header file could help here. (What about using
> > GSOnceMLog for that?)
>
> I really would rather save the developer time and expense of  
> porting an
> application only to have it say "NSException: This functionality is  
> not
> currently implemented" at runtime.  If it were me, I would be  
> supremely
> frustrated that I spent hours porting something only for it to fail  
> at runtime.

I'm with Fred on this one ... certainly on partially implemented  
classes, but also (though less strongly) on completely empty ones.
I think there is absolutely zero risk of someone wasting loads of  
time porting only to find something critical missing... as long as  
our documentation does not tell lies (and little chance of it even  
then).
We do need to make sure that the documentation is up to date, so it  
says which methods of which classes are unimplemented.

IMO partially implemented classes tell people that there is some hope  
of the classes being done in future ... or at least that the GNUstep  
project would look favourably upon people contributing in those  
areas.  In fact it would probably be good if unimplemented methods  
actually generated an NSLog  explicitly asking for an implementation  
to be contributed.  Maybe I should add a macro to NSDebug.h to do that?

Having a completely unimplemented class there gives us a good  
placeholder for the documentation that tells people that the class is  
unimplemented, and maybe what the current plans are for it.  I can  
see the argument here for removing the class (people aren't likely to  
think the class exists if there is no trace of it), but I think that  
a header file that's clearly a shell, and documentation that states  
that the class is unimplemented, is equally clear.  We could document  
such empty classes with a note to say that someone (or nobody) is  
working on them, and a pointer to the task list on the website for  
current status.