Re: Parameterizing on incomplete types

[Per Bothner <per at bothner dot com>]

On 12/01/2011 02:16 PM, Jamison Hope wrote:
> On Dec 1, 2011, at 4:28 PM, Per Bothner wrote:
>
> > On 12/01/2011 01:21 PM, Jamison Hope wrote:
> > > > It probably makes sense to generate the bridge methods at the same
> > > > time as we check for missing implementations.
> > >
> > > Where are they generated now?
> >
> > My point is: they're not. That needs to be implemented.
>
> At all? I thought you meant they weren't being generated here as a result
> of you commenting out the relevant part of ClassExp or because they don't
> yet work with this circular parameterization nonsense.

At all, as far as I can remember.

> I just meant for the regular (non-parameterized) case. For instance,
> when javac compiles:
>
> > // A.java
> > public class A
> > {
> > public A get() { return null; }
> > }
> >
> > // B.java
> > public class B extends A
> > {
> > public B get() { return null; }
> > }
>
> B.class ends up with an extra method:
>
> > Compiled from "B.java"
>
> > public class B extends A{
> > public B();
> > public B get();
> > public A get();
> > }
>
> The third method is marked SYNTHETIC|PUBLIC|BRIDGE (0x1041) and its
> implementation is
>
> aload_0
> invokevirtual 2 // call public B get()
> areturn
>
> and it exists so that B actually overrides A's get() method with an
> identical signature.
>
>
> But it turns out that when Kawa compiles the Scheme equivalent,
>
> > (define-simple-class A ()
> > ((get) ::A #!null))
> >
> > (define-simple-class B (A)
> > ((get) ::B #!null))
>
> B.class doesn't get the extra method:
>
> > Compiled from "bridge.scm"
> > public class bridge.B extends bridge.A{
> > public bridge.B get();
> > public bridge.B();
> > }

Right, that is missing.

> But maybe that's not what you're referring to as a bridge method.

That's one kind of bridge method.

There's another related kind when a parameterized type is instantiated.

In your example, the Kawa compiler generates the equivalent of

  public int compareTo(Foo o)
  {
    return x - o.x;
  }

However, the JVM knows nothing of generic parameters   The Comparable 
interface
takes an Object parameter, and the method taking a Foo does not match 
for dynamic
dispatch.  Hence we need a synthetic/bridge method to implement the 
interface:

  public int compareTo(Object o) { return compareTo((Foo) o); }
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/