[Top][All Lists]

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


From: Richard Frith-Macdonald
Subject: Re: GNUstep ROADMAP
Date: Mon, 28 Nov 2005 06:16:19 +0000

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


--- 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

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.

reply via email to

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