DSL | David R. MacIver

Anyone who has written a non-trivial amount of Swing will know the pain of menu definitions. They’re amazingly verbose.

Metascope used a reasonably large number of menus, and this verbosity had started to bother me, so I came up with a few syntactic hacks to clean it up. A “DSL” if you prefer. The result was relatively terse in comparison (only one superfluous line of code and two superfluous lines for the braces per menu item! In Java terms that’s practically a one liner).

Here’s essentially the same idea ported to Scala, with a few additional cute hacks and taking advantage of Scala’s first class functions to make it terser yet.

Some sample code:

val frame = new JFrame(){}

frame.setJMenuBar(new MenuBar{
new Menu("File"){
"Save" does { }
"Open" does { }
---
"Quit" does { System.exit(0) }
}
new Menu("Edit"){
"I like kitties" is true toggles (x => if(x) println("I like kitties") else println("I appear to be lying"))
new Menu("A sub menu"){
"There are no kitties in this submenu" does { }
}
}
});

frame.setSize(500, 500);
frame.setVisible(true);

The rest of the code to make this work is available here.

I (and some others in #scala) have been wondering recently about the state of play for dependency injection in Scala. This is mostly just a brain dump of a few thoughts and a request for feedback. If anyone has any good ideas, please share!

As I see it, most of the Java dependency injection frameworks should work fine for Scala. Guice won’t because of generics issues, and similarly the generics support from other frameworks (e.g. Spring’s type collections) won’t though, so you lose a great deal of type safety. You’re back to an almost Java-like level of type safety in fact. :) Also these don’t take advantage of many of Scala’s great features (higher order functions and a more advanced object system in particular), so the whole thing seems rather unsatisfactory.

I wondered briefly about a system based on abstract method injection using traits, but I couldn’t make it work in a satisfactory manner. The fact that you’d expose dependencies as defs was also unsatisfactory because it means that the compiler doesn’t know that they’re stable so you can’t e.g. import them.

There was some discussion in #scala last night about how “dependency injection is useless if you have higher order functions”. This seems like nonsense to me. A well designed scala program may have less need for DI because of the presence of higher order functions but the basic need for composing of modules (that’s what dependency injection frameworks really are after all – a module composition DSL) is still there, for more or less the same reason why Scala has objects as well as functions.

It’s not entirely clear to me how DI should work in Scala, both from an API and an implementation point of view. Something Guice-like might be a good starting point (but only a starting point! Porting Guice verbatim to Scala would almost certainly be a bad idea), but it’s not clear to me how one would even implement it in Scala. Part of the problem is that Scala lacks a satisfactory metaprogramming facility. It can use Java’s reflection, but the scala.reflect packages seem sadly meager. (There do seem to be a bunch of interesting sounding classes in there, but there appears to be no documentation or evidence of prior usage, so I can’t figure out what on earth they’re for).

David R. MacIver

Tag Archives: DSL

Make your menu definitions less irritating

Dependency injection in Scala