Re: OVERRIDE Multiple methods with the same name and argument types

[Per Bothner <per at bothner dot com>]

"Daniel Bonniot" <bonniot@cma.ensmp.fr> writes:

> * I think there was a bug in ClassType.getInterfaces
> The current version doesn't look for interfaces if one has a superclass. I
> suppose this was a typo.

Yes, it's a typo.  Thanks for catching it.

> gnu.bytecode.ClassType currently allows to have several methods with the
> same name and argument types, even when using the
> addMethod(String name, int flags, Type[] arg_types, Type return_type)
> that pretends to check if the method already exists.

addMethod(String, int, Type[], Type) should probably be deprecated.
The name is misleading, since it doesn't always add a new method.  The
functionality has been largely subsumed by getDeclaredMethod, which
are also more convenient.

> The problem is that addMethod creates a new one if the old has different
> return type and/or access flags. I consider this is a bug, since the
> classfile generated will be invalid.

Well, gnu.bytecode is not meant to prevent you from generating
invalid or meaningless classfiles.  It is meant to be a somewhat
low-level toolkit.  That doesn't mean we can't add some error-checking
when it is simple to catch errors!

> I encountered this problem using new PrimProcedure(ClassType classtype,
> Type[] argTypes). It led to several constructors in the same class with just
> differing flags (when a public constructor already existed, it created a new
> one).

Can you go into more detail?  I.e. who calls PrimProcedure, and why
are we getting a new constructor if one already exists?

> I propose:
> * Add a getDeclaredMethod(String name, Type[] arg_types, Type return_type)
> to ClassType. This is a convenient method that calls
> getDeclaredMethod(String name, Type[] arg_types) and then if a method was
> found, it verifies that its return type is the same, otherwise throws an
> Error.

I'm not sure I like that.  I'm not sure it belongs in gnu.bytecode.
For example, if there is an error because a Scheme programmer
mis-wrote primitive-virtual-method (for example), we want a
standard compiler error message, including source line number.
Throwing an exception should be avoided.  We should throw Error
to indicate internal errors in Kawa, not for other compile-time errors.

> * Modify PrimProcedure, so that it first checks if the method exists (in
> that case verify the static flag is correct), and if not creates a new one.

Again, I think it's the wrong place to signal the error - you should
try to catch it earlier.

Have you looked at whether the classes in gnu.kawa.reflect will
work for you?
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/