On 28 Nov 2005, at 02:17, Gregory John Casamento wrote:
Fred,
--- Fred Kiefer <[EMAIL PROTECTED]> 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.
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
