You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This feature should probably support two formats: JavaScript source code for languages that compile to JS and Java bytecode. The latter allows us to support precompiled modules.
One open question is how Java modules should be provided: raw byte arrays or prelinked and -loaded classes?
That sounds like a really good feature. It also means that we'll be able to integrate Clojure, Groovy, Scala, Erlang, Python, Ruby, and every other language that uses the JVM seamlessly with Ringo. That's a really big plus point for a growing CommonJS implementation.
I just have one doubt - if we'll be using Java class files as modules then I assume that we'll be exporting the class itself. In that case the static members of the class will be the exported methods and properties of the required object right? So we'll be able to require a class and create instances of it. What about including class files. Then we'll only be able to use the static members if I'm not mistaken.
Also, how will interfaces be required or included in Ringo? I think that's something that needs to be given some thought.
The ability to load Java class files here does not mean any class files. This will be limited to JS scripts compiled to class files by Rhino.
We will not load and represent generic Java classes as CommonJS modules. The semantics wouldn't be clear, and we can already access these classes with Rhino as it is.
Node.js supports a require.extensions object to register handlers for loading modules from alternative languages, using the file extension as keys.
Also see usage in coffee-script: http://jashkenas.github.com/coffee-script/documentation/docs/coffee-script.html
The text was updated successfully, but these errors were encountered: