2009/12/21 Rich Hickey <[email protected]>: >> Why bother? Why not just stop once you've parsed enough to know the >> classes & methods, and return some representation of those? >> > > Generating .class files isn't necessarily 'overkill'. I agree with > Per, this is a standard representation. Given such .class files in the > classpath, all of our existing compilers and tools will 'just work', > right now. Reflection will work, etc.
One issue to bear in mind is that this potentially generates a lot of stubs where it doesn't need to. With Scala at least the generation of a large number of small class files is a big performance hit. Potentially doubling the number generated (even if the version generated in the first pass is much smaller) is going to slow down the compilation process quite a lot, potentially for no reason at all: If another language never requests that class then there was no need to generate the stub. This could easily be addressed by an API (and if that API wants to generate class stubs, that's not a problem) which asks for classes rather than generating them all up front. Another potential issue to worry about with Scala is that type inference across language boundaries introduces you to a world of pain. As long as only one language involved is type inferred (e.g. Java + Scala) this isn't a big deal, but when you've got cyclic type inference dependencies between languages you're going to suffer. -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
