Re: Eclipse 3.0 and unimplemented methods proposal

[Andrew John Hughes]

On Fri, 2004-07-02 at 14:15, Dalibor Topic wrote:
> Andrew John Hughes wrote:
> 
> > Sounds good to me.  I wouldn't actually throw out any methods, simply
> > because eventually someone will have to put it back in and that's just
> > more time -- there's usually also a good reason a method hook has been
> > put in, I imagine.  I can see the situation where someone would be
> > implementing something, find they need to support an optional method
> > somewhere else and put an empty hook in.  I just really needs to be the
> > policy to have these hooks as throwing Errors rather than simply sending
> > back nulls (which in a lot of cases is a valid result -- so the calling
> > code expects it and takes an appropriate codepath, not knowing that the
> > actual result is an error).  I'm more for an Error throw rather than an
> > Exception, simply because bad calling code may just swallow exceptions. 
> > I don't think any of it will expect NotImplemented, and we need
> > something that will unavoidably spit out the result of calling a dead
> > method.  I may be barking up the wrong tree here -- if NotImplemented
> > allows this behaviour by descending from an appropriate superclass, then
> > by all means use this.  But I think the very thing we want to avoid is
> > silent handling of these hooks, whether it be by null or an exception
> > being swallowed by catch (Exception e) {} (and yes people do this...).
> 
> Bikeshed! :) [1]
> 
> cheers,
> dalibor topic
> 
> [1] Discussion of NotImplementedYet has been done to death last year. It 
> just gets people riled up about nothing instead of actually writing the 
> code to implement the not yet implemented parts. grep FIXME and start 
> hacking :)

Okay, I've just read that thread.  I see lots of round-about discussion,
but no decision on this.  Hence, that's why its come up again.

Based on my views and what I've just read, I'd like to take a slight
more formal attack on this problem and present the following proposal
for how we can possibly solve this problem, hopefully without getting
mired in another discussion about exception semantics.  Please note that
I'll state here and now that I'm prepared to sit down and do the hard
work to make this actually happen.  I don't think the current situation
is acceptable for anyone, that much already appears to have been
agreed.  Please, for the sanity of the list, make any feedback on this a
rational well-founded summary of why you want the current status quo or
a different solution to apply.
Firstly, a little background.  I came to GNU Classpath as a result of
using it for Java code.  In using it, I did actually experience this
problem.  I was fortunate.  Some kind hacker threw such a runtime error,
so I could see the problem and knew that my code wasn't the fault.  I
didn't have to chase into Classpath's code to find the error, and was
given the choice between fixing the problem or reverting to Sun.  Sorry
to say, but this was assignment work with a deadline, so at the time I
had to do the latter.  In another situation, I may have taken the other
option.  You're less likely to find developers wanting to take this
option if they become annoyed with the developers after tracking down
the hole.  At the time, I didn't have the Classpath code available and
would probably have spent a lot of unnecessary time hacking my own code
in vein.  My proposal follows:

* -- I suggest the creation of a fresh GNU Classpath-specific runtime
error to handle the case of a method or sub-part of a method being
unhandled in the current implementation.  This should give behaviour
similar to that of a missing library and be untrappable.  How much of a
real difference is there between a missing 'libxxx.so' and a missing
method, except that one is a file and one is part of a file?  Both may
relate to optional functionality, but the library would still be
required...
* -- The existing null-based situation should be avoided as returning
a null value is a valid implementation practise.  It is also silent and
leads to an unimplemented method causing later errors.
* -- An exception should be avoided so that unimplemented methods can't
be caught.  Bad programming such as catch (Exception e) {} which DOES
exist would just gobble these up.  The programmer should be made aware
when testing, regardless, of the fact that something is not implemented.
Exceptions would also change the message signature and make it harder to
throw this away at a later date.  Most Java programmers are used to
Sun's implementation, which works on the proprietary system of full
implementations only (or just about).  Therefore, unimplemented methods
are not generally expected.  Certainly, user code shouldn't be trying to
handle this case, which may later disappear, and allowing it to be
passed over runs into similar problems as with null -- the user's code
starts taking code paths based on code results that were never expected
and would never occur elsewhere.  A runtime error makes the point clear
-- the user has enough to deal with already without having to handle
Classpath-specific errors in their code.
* -- An existing exception or error is even less of an option.  There is
a high risk that it is already been used somewhere for something, and
again, the user's code may affect it.  If it already exists, the user
may make use of it in their own code, for example.  I know I've used
UnsupportedOperationException myself...
* -- A call to implement all these methods is simply not a viable fix in
the short term.  It's basically equivalent to saying 'go and finish
Classpath'.  Using this method also allows for partial implementations,
so some code paths will be supported, and some won't.  
* -- Killing the methods is not an option.  Some will have come to rely
on them, including implemented Classpath methods.  It also causes binary
compatibility problems with something compiled by a Sun binary (although
this is already an issue with the still missing methods).
* -- As mentioned in discussion, mere existence allows the passing of
the first test for a method -- it can be called!  We can then build up
Mauve tests and documentation, without an implementation.  This would
provide further routes into implementing it.
* -- Adding errors makes testing applications more viable, including
without the source (for example, someone like myself who installs
Classpath from Debian to work with).  Testing real applications seems to
be the most valuable way of ascertaining which methods to implement,
rather than trying to get them all at once.  It also shows up which are
more needed and gives us priority.  There is also an inroad for new
developers here, who run the code, see an error and go out to fix it. 
Hopefully, they then commit the patch!
* -- If such an error occurs in one of the methods a developer uses,
they have options -- implement it, find another implementation, use a
different solution in their code.  Less clear ways of doing this cause
greater confusion between Classpath and developer errors.
* -- The error should be able to be discarded.   A full implementation
of Classpath has none of these, and can compile without the error class.
This provides a nice acid test of compatibility, arguably easier than
grepping for FIXMEs, etc.  AFAICS, it would then be possible even
without source.  As mentioned in another thread, a stable branch of
Classpath could provide such a 'unimplemented method free' source base. 
These are signposts along the road, rather than part of the final
solution.  Equally, this is why we shouldn't make it an exception
resulting in message signature changes.

That's probably about enough reasons, although I could probably think of
more.  What I want now is some strong reasons why there are problems
with this.  Suggested unimplemented code could be (and no this isn't a
definitive answer codewise -- this is not the primary discussion
here...):

public void VeryComplicatedUnimplementedMethod(int x, float y, String z)
{
        /* FIXME: Implement this */
        throw new UnimplementedMethodError(MessageFormat.format("Unimplemented
method called with parameters {0}, {1} and {2} -- please consider
contributing
to GNU Classpath to help solve this problem.", new Object[]{new
Integer(x), new Float(y), z}));
}

And, yes, you'd need concatenation operators in there :-)
The stack trace would include the method name, which is why I avoided
it.  UnimplementedMethodError would be in a GNU Classpath specific
package, and be eventually removable.

Anyway, the floor is over to you guys.  Be gentle ;-)
-- 
Andrew :-)
 
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
 
Value your freedom, or you will lose it, teaches history.
`Don't bother us with politics' respond those who don't want to learn.

signature.asc
Description: This is a digitally signed message part