And to be clear, while I am perfectly happy to suggest that Scala should get its own classloader, I think generating a class/interface for A with B would be a terrible idea.

If intersection types correspond to classes then the subtyping relationship has to match the inheritance one. If A with B with C has its own class/interface and I wish to assign it to A  with B then that interface needs to extend A with B. And B with C. And A with C. Thus you introduce a combinatorial explosion where every time you have a class with n traits you need to generate 2^n intersection types in order to fit it into the intersection hierarchy.

On Tue, Dec 2, 2008 at 12:29 PM, Ricky Clarkson <ricky.clarkson <at> gmail.com> wrote:

Just to be clear, I'm not suggesting that Scala should use its own classloader, just that supporting what Bruno wants wouldn't require abandoning separate compilation or moving off the JVM.  Also, I expect it doesn't cause a huge problem to have two jar files both containing a generated AB.class (or a mangled name).

2008/12/2 David MacIver <david.maciver <at> gmail.com>

On Tue, Dec 2, 2008 at 11:38 AM, Geoffrey Alan Washburn <geoffrey.washburn <at> epfl.ch> wrote:

Ricky Clarkson wrote:

Would I be correct in saying that to support what Bruno wants without problems Scala would have to introduce its own classloader?

Using a custom classloader might work.  However, based upon what Martin has told me, the Java classloader design is completely broken because it is not compositional.  Therefore, requiring a custom classloader for Scala programs completely rules out the ability to use Scala in a number of important places, like Eclipse, where an alternate classloader cannot be specified.

No, I don't think that's true. As long as the classloader setup is such that it correctly delegates to a provided parent classloader it should be fine to make work. e.g. it's perfectly fine to run JRuby inside an OSGi container, and JRuby does much crazier things with classloaders than Scala would ever need.