RE: RFC: Generics branch VM interface

[Jeroen Frijters]

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