This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: Parameterizing on incomplete types
On 12/03/2011 10:59 AM, Jamison Hope wrote:
OK, here's what I've got so far. It appears to handle our Comparable
test case
(define-simple-class Foo (java.lang.Comparable[Foo])
(x ::int)
((compare-to (o ::Foo)) ::int
(- x o:x)))
generating a bridge method equivalent to
public int compareTo(java.lang.Object o)
{
return this.compareTo((Foo) o);
}
That's a pretty good start. Thanks!
The patch consists of two parts: the new
Compilation#generateBridgeMethod(),
and a few lines added to ClassExp#compileMembers.
I would prefer to keep generateBridgeMethod in ClassExp,
even if it has to be a static method with an explicit Compilation
method: It's only called from one class, and there is too much stuff
in Compilation.java anyway.
generateBridgeMethod takes an existing method and desired arg/return types,
creates a new method with the desired signature and emits bytecode to
checkcast
its args and then call the existing method. In my limited testing so
far, this
is the same bytecode generated by javac for similar cases.
The addition to ClassExp sits after the call to getImplMethods() where
the current
"missing implementation" error is. Before triggering that error, we look
to see
if the problem was 0 implementations found (as opposed to multiple,
which is a
different problem), and if so, we look to see if there's a method with
the right
name and number of args but wrong signature. If there is such a method,
then
we check its arg types and return type to see if they're compatible with
the
required signature, and if so we generate the bridge method. If not,
then we still
do the error message.
One problem is this doesn't handle multiple overloaded methods with the
same number of parameters. You might have to iterate over the list
returned from getDeclaredMethods() and check each if it's bridgeable.
(At the least add a comment about the limitation.)
There is also the case of an abstract class that implements an
instantiated method. Should we generate the bridge method in the
abstract class, or only when we get to a concrete class? Ideally,
I think the former. (I'm guessing javac does that, but I haven't
verified it.) But this is fine-tuning.
Ideally, one would go carefully through the Java Language Specification
to better understand the issues. That is probably best done if/when
we add wildcard support, definition of generic types, and sotherwise
start approaching "completeness" (i.e. Java parity). We quite a ways
from that. (I would like a mechanism where generic instantiation can
inherit or default a wildcard from the type declaration, as in Scala.)
I'm not handling covariant returns yet, because I'm not sure where/how
to check
for those. We could use the same generateBridgeMethod there, but in that
case the
checkcast instructions aren't needed. I suppose I should put the
emitCheckcast
inside of something like "if
(bridge_arg_types[i].compare(src_arg_types[i]) != 0)".
That's handled automatically by the castNeeded in emitCheckCast.
--
--Per Bothner
per@bothner.com http://per.bothner.com/