[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RFC: Generics branch VM interface
From: |
Jeroen Frijters |
Subject: |
RE: RFC: Generics branch VM interface |
Date: |
Fri, 17 Jun 2005 08:51:38 +0200 |
Andrew John Hughes wrote:
> Keeping the VM interfaces in sync sounds like a good idea to me, but
> keep a couple of things in mind:
>
> 1) A lot of VM differences between the two will be due to new methods
> that just don't exist outside the generics branch e.g.
> cast(), isEnum().
> You mention two of these below. Thus, you'd never get exact identical
> copies without introducing lots of generic library code into
> HEAD, which we simply can't do at this stage.
Sorry, I should have been more clear. What I would like to see is that
the interface between the Foo and VMFoo classes doesn't contain any
types that are not in HEAD. This way VMs that replace the VM* classes
can use one set of VM classes for both HEAD and the generics branch.
> Also, on reading the new specs. for this stuff, something
> seems to apply that this run-time dropping may only be temporary (i.e.
> that the idea is to ween people off non-generic code). But I'd be
> really interested to hear the opinion of others on this.
If seen this sentiment too, but I don't think it is realistic. It will
break too much code.
> > This means, for example, that in VMClass, we use Class instead of
> > Class<T>. In some cases this requires additional casts in the
> > corresponding class, but these casts are removed by the
> > compiler so they don't affect performance or code size.
>
> I don't see how much this gains, as you'd never get identical VM
> interfaces because the majority is new stuff. Unless you're proposing
> that VMs implement this without having the stuff in the class library,
> which seems a little strange.
I hope it is clearer now, given that I've explained above that my angle
is that my VM replaces all the VM* classes. Please let me know if it
isn't.
Regards,
Jeroen