🚀 go-pugleaf

Jacob Weintraub wrote:
> 
> I believe that there are two misunderstandings here.
> 
> 1) Method lookup on overriden functions is based solely on the
> arguments to the function, not on the return type.  There is a
> requirement that "The return type of an overriding method be
> assignable to the return type of the overridden method."
> 
> 2) Overridden methods of a superclass can be called by
> using the super.methodname() syntax.
> 
> See 6.4.9 and 9.7 in the beta documentation.
> 

No, there are no misunderstandings.

1) Semantically, you are right, but that has nothing to do with
my point.  That point is that the
current lookup mechanism does not implement the
semantics correctly.  In the current java implementation,
the return type IS used (wrongly) during lookup, causing 
the override bug I describe.  As I pointed out, this form
of the problem easy to fix (but is still a nasty hole in the
current system).

2) I understand how to use super.  The point is that people
outside a class should NEVER be able to call the overridden
method directly; that violates the object's design integrity
(and makes it more fragile for future changes).
Invoking it from within the object intentionally using super is
an entirely different operation.

More importantly:
You may have missed the little paragraph at the end mentioning
the overload form of the problem.  It can be PROVED that the
overload form of the problem CANNOT be solved without
changing the .class distribution file format.