Re: Unimplemented methods

[Nicola Pero]

yes - your points are good ... there is likely no real perfect solution to
the problem ... the only real solution is ... implementing the missing
features.  :-)


> > in conclusion, my opinion for unimplemented facilities is:
> > 
> >  - methods setting unessential properties of gui elements should be there
> >    with an implementation doing nothing, so that ported applications still
> >    run properly even if they are unimplemented;
> > 
> >  - methods doing something essential should *not* be there at all.
> >    they should be commented out in the header file as well.
> >    that will help people trying to port code, so they know immediately
> >    what methods will cause problems, because the compiler will emit
> >    warnings when they call the methods.
> 
> At first I thought that this is a very reasonable solution. Than doubts
> came, who should decide which methods are essential which aren't? After
> more thinking I would even reverse the argument. 
> 
> In the last year I did a lot of review of old GNUstep code, often code
> that has been around for some time. What was typical here was code that
> did things that shouldn't be done at that place, but was supposed to be
> in another class. Probably at the time the code was written this other
> class was totally missing, so who ever needed its behaviour wrote it
> himself, locally. I had to do a lot of reorganization of code to put
> this right again. So my feeling to this question is that all classes and
> methods of OpenStep (and MacOSX) should be present in  GNUstep, even
> with no code behind it. When there is no method, nobody can call it and
> also nobody will implement it. Who ever needs it wont implement that
> method, but do some strange workaround somewhere else. 
> 
> Of course Nicola is right that all those methods should warn users that
> they are not implemented. But where should we stop? If there is some
> partial implementation, as is often the case in GNUstep, shouldn't we
> warn also? What we need is different levels of warnings, that can be
> switched on and off with compile time or runtime switches. We could use
> NSDebugLog for this.
> Even essential methods should be defined, and anybody who wants to know
> why her application looks or behaves different in GNUstep switches on
> this reporting and the missing methods show themselves.