> projects now I can't imagine being that statically bound. My impression > is that C#/.NET has similar (if perhaps slightly lessened) restrictions.
I don't think .NET is any less dynamic than the JVM - you can load assemblies and types on the fly just like Java. But the execution of this feature on .NET isn't nearly as nice as the JVM. For example, if you are using the emit APIs you have a lot less flexibility to lazy load types. In Java you can make references to external types, methods, fields and they are loaded when needed. In .NET you can't emit those references unless you also emit what is being referenced - it kind of turns into a big hairball. And I've mentioned before you have to generate a file on disk to get line numbers which seems silly - you can't do strictly in memory. > What bytecode-level differences do you think would have been the largest > issues? I understand that CLR has statically-typed local variables at > the bytecode level too, so that's probably one (JRuby is *very* liberal > about what it stuffs in local variables). And I would imagine IL > reflects the much-more-static nature of CLR. Having investigated it > yourself, I'd be interested in hearing your take. Yes indeed you need to emit typed local variable definitions - although I haven't found it too bad. It isn't much different that what the JVM verifier expects. And I expect some of the future JVM "pre-verification meta-data" will amount to the same thing. Another thing is that to compile something like "a = b[c] = d" requires a bit of stack manipulation to leave the value of d on the stack for assignment to a. In Java this is pretty easy. On the CLR it requires generating a local variable because you can't really manipulate the stack. There are also special opcodes for leaving try/finally blocks that are a bit twisted, but they aren't that bad. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
