Richard, --- Richard Frith-Macdonald <[EMAIL PROTECTED]> wrote:
> 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. Okay, you've convinced me. I agree. :) So long as the documentation is clear, I see no issue. Later, GJC Gregory John Casamento -- Principal Consultant, Open Logic Corp. (A MD Corp.) ## Maintainer of Gorm (IB Equiv.) for GNUstep. _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev