FWIW ($0.02??), my feeling is that too many people (or tools) will be confused if they see a .class file and it isn't really exactly that. At least a different extension will help to avoid such confusion.
You mentioned plans for a compiler that will generate class files. Will it translate the output from this compiler or be different? If it will be the backend for this compiler, then having a different extension would also help avoid confusion. dean On 10/18/07, Charles Oliver Nutter <[EMAIL PROTECTED]> wrote: > > Peter K Chan wrote: > > Charlie, > > So, I see the semantic mismatch, but what is the technical reason > for > > having a separate extension? > > > > I see some benefits of using the standard .class extension, such > as > > being able to compile JRuby compiled bytecode into native code (e.g. > using the > > JET compiler), or to run an obfuscator on the class files (imagine how > > confused if someone were to try to decompile JRuby code to Java...). > Besides, > > wouldn't this require a separate classloader to load the byte code? > > But we already need a separate classloader to allow classes to be loaded > and defined at runtime (generated invokers, JIT-compiled stuff, etc), so > that's not a big requirement. > > The benefits you state are pretty good ones though...which is why I'm > waffling on this. I feel like there should be better identification for > the files as being compiled Ruby rather than "normal" compiled Java, but > there's not really any good technical reasons for a different extension. > > It just feels more right to me for some reason. > > - Charlie > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email > > -- Dean Wampler http://www.objectmentor.com http://www.aspectprogramming.com http://aquarium.rubyforge.org http://www.contract4j.org
