) to give Scala another try, the fact that both Venkat Subramanian and Alex Miller presented great talks and compelling arguments on the subject convinced me to get back on track.Without getting into fine grained details and the static vs dynamic debate, I think one of the most compelling features Scala offers to Java developers is better concurrency options. Being a polyglot programming believer myself I made it my quest on this past weekend to find a way for having a Scala enabled backend and a Groovy powered frontend, yes I'm talking about a Griffon application that knows how to work its magic along with Scala. Both Groovy and Scala can talk to each other as easily as the other can talk to Java, this means the impedance mismatch is pretty much non-existent, but a problem arises when calling Scala from Groovy and having Scala replying back to another Groovy object which is not the caller, you know, like an asynchronous invocation is usually performed. We desire this asynchronous behavior because the Scala backend might fire up many actors to do its thing and notify the Groovy frontend (int this case a Groovy Controller) via an update on the Model (also a Groovy class); because there is no joint compilation option between these two languages a different approach was needed.
So then it happened like serendipity, after tweeting praises about Scala's matchers and regexp support then came the dynamic duo of Daniel Spiewak and Debasish Ghosh with a powerful Scala feature as a candidate solution: Structural Types. They enable in a sense statically correct duck typing, if Scala knows at least the signature of a method on the expected callback object I might be able to pull this one off, turns out it was possible after all!
The Scala code will be expecting an object that conforms to a particular callback signature and not a particular class, on the other side of the story the Groovy code will need the compiled Scala classes to make the call, this means that the Scala code can be compiled first and then the regular procedure to compile the Groovy/Java code will be performed, this behavior can be easily attained by registering a build event listener on the target Griffon application, or... with a Griffon plugin
but before we get into that let me show you a very basic example of Groovy/Scala working together. The following screenshots show a rather crude application (a textField and a button), whatever you type on the textfield will be sent to the Scala backend, when said backend has finished processing its input it will return an updated value based on that input, finally the Groovy frontend will display that value using a message dialog. |
 |
Let's look at the Scala code first
ScalaGreeter.greet expects a String parameter (this would be the textField's text) and another object whose type is unknown, but what can be known about that object is that it has a public method named setOutput that accepts a String as value; that object is the Model
Thanks to the Groovy compiler's magic each property will have a getter/setter, meaning that the Model does contain a setOutput(String) method as expected by the Scala code. Before showing how the interaction between Groovy/Scala can be wired up let me present the View
Alright, so the final piece of the puzzle is the Controller, it is after all the one responsible for calling the Scala code. As noted earlier there is no impedance mismatch between Groovy and Scala, so the Controller can call ScalaGreet as if it were a regular Groovy class (or a Java class for that matter)
And there you have it. By registering a PropertyChangeListener on model.output the Controller will be able to react to that property's value being set by the Scala portion of the application. Now imagine changing ScalaGreet with some highly concurrent code handled by Scala actors, that is where things become interesting don't you think? About the griffon-scala plugin, it has not been released yet, but you can expect to see another announcement soon.
Keep on Groovying! (in a scalable way
)
