New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
make Scala JSR 223 compliant #874
Comments
Imported From: https://issues.scala-lang.org/browse/SI-874?orig=1 |
@lexspoon said: However, there is a question about whether it can pratically be done. Interpreter.bind takes a type as an argument. The setAttribute() call in the example code does not. Is there another setAttribute() call that could be used to pass in a type? If not, it requires some deep though to figure out how to get Scala to fit into what JSR 223 expects. Treating label as type "Any" is unkikely to give a good scripting experience. By the way, if you want to know whether an interpret attempt succeeds when using Interpreter.interpret(), simply look at the return value. |
@rjolly said: http://java.sun.com/javase/6/docs/api/javax/script/ScriptContext.html void setAttribute(String name, Object value, int scope) Hence, there is a type unsafety in this scripting interface, but I think it is by design : all scripts don't have the same type system (as Java). interp.interpret("ret(0)="+str) match {
case InterpreterResults.Success => ret(0) toString
case InterpreterResults.Error => "error"
case _ => ""
} ? Beside, what would be useful is if the interpret(str) method could return not just a success flag, but the whole evaluation of the expression (when the input statement is an expression), as is the case with |
@dragos said: |
@lexspoon said: |
@odersky said: |
Mateusz Fioka (mateusz.fiolka) said: My approach for discovering types is simple:
I have also added some code to make the script use scriptResult variable rather then result(0) because it looks perlish/magical The project I mention also has some junit tests that I wrote which should work with any jsr223 implementation for Scala. It also could be useful to integrate it with the icfx project. If there are some downsides related to the way I did the type bindings, then I would happily like to hear about them. |
michid4 said:
Currently I'm working on untangling the scripting engine from Sling. My aim is to make it as versatile as possible. That is, it should run within/without OSGi and should be of course independent from Sling (or any other framework). |
michid4 said: |
@SethTisue said: |
michid4 said:
That's the same on I mentioned here: https://lampsvn.epfl.ch/trac/scala/ticket/874#comment:11 |
@retronym said (edited by @SethTisue on Sep 8, 2015 6:49:01 PM UTC): |
@adriaanm said: |
Currently, to use Scala as a scripting engine, one has to do:
It would be nice if one could do instead:
Plus, as was pointed elsewhere, the compiler used in the background by the interpreter should not need a filesystem (for instance if scripting is to be used on handheld devices etc.)
The text was updated successfully, but these errors were encountered: