Re: Re: Type Synonyms in Scala
2008-12-02 15:28:17 GMT
Some examples (there are probably more, but these are the ones that spring to mind):
- structural typing could be made to not use reflection, raising it from the status of painfully slow to as fast as any other interface invocation.
- type erasure could be smote with a big stick giving us fully reified generics
- the traits implementation's support for separate compilation could be improved dramatically
- compiled code size could be reduced by a very large amount (probably up to 50%) by support for dynamically generated method handles.
- FunctionN, TupleN, etc. could be implemented in such a way as to allow arbitrarily large values of N.
Almost all of these could be done without the custom classloader (the reified generics one can't), but the custom classloader makes it dramatically easier both for the language implementers and the end users.
What possibilities? I'd be interested to see whether it would be worth the extra deployment difficulty.
I suppose structural typing could be made not to use reflection, for example.2008/12/2 David MacIver <david.maciver <at> gmail.com>On Tue, Dec 2, 2008 at 2:54 PM, David J. Biesack <David.Biesack <at> sas.com> wrote:Perhaps. But these are problems that are already being solved in the contexts of other JVM languages: JRuby (in particular JRuby + Glassfish showcases a lot of potential issues as being very surmountable), Groovy, Clojure, etc. and it opens up a lot of possibilities.> Date: Tue, 2 Dec 2008 12:50:43 +0000
> From: David MacIver <david.maciver <at> gmail.com>>Requiring a Scala classloader would necessitate a *lot* of deployment
> And to be clear, while I am perfectly happy to suggest that Scala should get
> its own classloader,
scenario validation (especially when integrating with Java; think J2EE,
OSGI, Java module system JSR 277, javax.tools, etc.), where interaction
and integration with existing framework classloaders can be cumbersome
at best.
RSS Feed