Category Archives: Scala

C#-Style Events In Scala

As you may know, C# has a rather lovely little feature whereby you can setup an event on a class, like so:

public event EventHandler MyEvent;

Where "EventHandler" is a delegate (i.e. function pointer) type. The built-in EventHandler delegate just has the signature (Object, EventArgs) -> Void, so from within the class we can invoke the event like so:

if (MyEvent != null)
{ MyEvent(this, EventArgs.Empty); }

And this will cause any anonymous delegates or methods which have been attached to the event to be invoked with those arguments. This attachment and detachment is done like so:

myInstance.MyEvent += this.myInstance_MyEvent;
myInstance.MyEvent -= this.myInstance_MyEvent;

Where we have created a method on the subscribing instance called myInstance_MyEvent with the appropriate signature. We could also have supplied an anonymous delegate to the event, but would need to keep a reference to it around in order to remove it later:

EventHandler myHandler = delegate(object sender, EventArgs e) { Console.WriteLine("MyEvent triggered from " + sender); };

myInstance.MyEvent += myHandler;
myInstance.MyEvent -= myHandler;

Right, so far so ordinary. As part of my ongoing quest to reimplement C# in Scala (see also here) , I'll try and code up an equivalent system in Scala, which does not have a built in event system. The approach I took was to define a class, Event:

class Event[T]() {

  private var invocationList : List[T => Unit] = Nil

  def apply(args : T) {
    for (val invoker <- invocationList) {

  def +=(invoker : T => Unit) {
    invocationList = invoker :: invocationList

  def -=(invoker : T => Unit) {
    invocationList = invocationList filter ((x : T => Unit) => (x != invoker))


This is a pretty simple bit of code. It just defines two methods with the same names as the operators of C# which add or remove the functions they receive as arguments to and from an invocation list, and a method with the special name "apply" which will be invoked when the event is supplied with an argument list by the usual juxtaposition convention. Now, let's take a look at some example code that uses this:

val myEvent = new Event[Int]()

val functionValue = ((x : Int) => println("Function value called with " + x))
myEvent += functionValue
myEvent -= functionValue

This will simply print "Anonymous function called with 4". Great! Looks like a very direct equivalent of C#s mechanism. But alas, there is a bit of a subtlety. What about if we have a method such as this:

def method(x : Int) = println("Class method called with " + x)

And we then try and do something like this:

myEvent += method
myEvent -= method

What you actually find is that you get notification on the console of both the 2 and the 3 that were passed to the event! Why is this? Well, if you look at the generated code in a Java decompiler you will find that actually Scala internally creates a class to coerce the class method into its internal representation of a function. The problem is that his coercion is done separately for both usages of "method", which leads to two function objects which are not reference equal and hence the invocation list never has its item removed!

Sidenote: actually, interestingly the Scala compiler creates entirely different CLASSES for each coercion, even though these classes have identical functionality!

The only sensible way this code could be fixed is for a more intuitive implementation of equality to be given to the adapter classes generated in this way (obviously we cannot compare functions for equality in general!).

Happily, there is a workaround, but it smells a bit. Instead of declaring a method like that, declare it like this:

val memberFunctionValue = (x : Int) => {
  println("Member function value called with " + x)

This creates a member function value instead of a method, which looks the same for its callers from Scala code (but not from Java). This means that reference equality does the right thing when trying to remove the "method" from the event.

Another irritating limitation of the approach is that anyone is allowed to raise the event. This is in contrast to C#, where only the class hierarchy that declared it has such access: a much better design principle. On the basis that Scala supports syntax such as the following for property access:

var _foo : Int

def foo() = _foo

def foo_=(value : Int) {
  _foo = value

I tried to define a class like this:

class MyClass {

    private val _myEvent = new Event[Int]()

    public def myEvent_+=(function : Int => Unit) {
        _myEvent += function

    public def myEvent_-=(function : Int => Unit) {
        _myEvent -= function

    public def doSomethingCausingMyEventToRaise() {
        // ...
        // ...


This encapsulates the event, allowing us to control exactly who can invoke it. Unfortunately, code of the form:

val myInstance = new MyClass
myInstance.myEvent += method
myInstance.myEvent -= method

Does not compile: the myEvent_ style method names I added to the class are simply not used, and that code instead tries to find a (non existent) field called myEvent in MyClass. Of course, calling the myEvent_ methods of MyClass directly does work, but we lose the nice feature of the syntax whereby events feel like they are built into the language.

So overall things didn't work out great for replicating C# events in Scala, but it was still an interesting voyage of discovery. Furthermore, if we could convince the language designers to support desugaring for arbitrary methods of the form "foo_[some symbols]" rather than just the special case of properties we could begin to do some rather interesting things...

Implementing The Disposable Pattern In Scala

One excellent feature of the CLR in general and C# in particular is deterministic finalization: the ability to control when resources are released. In C# this is realized with the IDisposable interface and the "using" keyword. Effectively, the statements:

using (File myFile = File.Open("foo.txt"))
{ /* Do something with myFile */ }

Are equivalent to the following

File myFile = File.Open("foo.txt");
{ /* Do something with myFile */ }
{ myFile.Dispose(); }

The usual use of the Dispose method which is, as you can see above, called when "myFile" goes out of scope is to perform general clean up. In this case it would release any open handles to the file, if any: doing so in this deterministic manner is in most situations a much better idea than waiting until the garbage collector gets around to finalizing your object and doing the cleanup there, although File will of course support this paradigm to ensure that its open handles are eventually released.

There are actually more interesting uses than resource management that are made of the using keyword in C#, such as transaction management (the scope of the transaction is the scope of the using block), mock playback (mocks are automatically verified by Dispose) and many more of the class of scope management problems encountered during everyday programming (e.g. calling Begin/EndUpdate on a particular Control while you do lots of setup work on it). Hopefully this litany of examples has convinced you that we simply must have "using" added to Java - but alas that particular behemoth is unlikely to acquire this rather nice feature any time soon. Instead I have elected to show you how we can add this feature to a JVM based language, Scala, using the advanced features of its type system and functional programming paradigm.

Right, let's get started! First, let's have an interface for all things we want to consider Disposable, just as in C#:

trait Disposable[S] {
  def dispose()

Don't let the word "trait" throw you: although you can do some cool stuff with traits, for our purposes they are just like Java's interfaces. We have simply defined a method, dispose, on the Disposable interface that will be called to do cleanup.

Now, we could just have all things we use "using" with implement this interface, but this feels kind of limiting. This is all well and good for our own classes, but what about interfacing with Java code that doesn't know a thing about our interface? In particular, it would be nice to be able to use our new functionality with JDBC and SWT, which have a common pattern of making use of close and dispose methods respectively to perform cleanup. So, let's define two implicit conversions, known as "views" in Scala-land, from objects that define methods with those signatures to a Disposable!

  implicit def close2disposable[S](what : S { def close() }) : Disposable[S] =
    new Disposable[S] {
      def dispose() {
        try {
        catch {
          case t => ()

  implicit def dispose2disposable[S](what : S { def dispose() }) : Disposable[S] =
    new Disposable[S] {
      def dispose() {

This is cool stuff. These function is making use of a very nice feature of Scalas type system, structural subtyping, to operate on arbitrary objects that define particular methods. For example, the type

S { def close() }

defines a type of class S which must contain the method close, which takes no arguments and returns void (aka Unit, in Scala). With this, it is statically valid to call close() on any variable of type S within the body of our implicit conversion, and I make use of this by returning a new anonymous inner class which implements Disposable and calls the close method of the implicitly converted variable when dispose is invoked (wrapping it in appropriate exception handling, since e.g. the "close" method in JDBC can throw SQLException, and we don't want that masking exceptions thrown in the body of the using block). We define the view on things with a dispose method similarly, but this time we needn't handle exceptions since we assume anything with a dispose method is already going to be well behaved.

Notice that this is effectively statically safe duck typing, so you can have all the flexibility of a dynamic language like Python in exactly the places you need it, but keep the compile time guarantees of Scala in the majority of your code base, where you don't need that power.

Now all that remains to be done is to define the using "keyword" itself. There isn't a way to perfectly emulate the C# syntax in Scala, to the best of my knowledge, but we can come pretty damn close by defining a function which takes one curried argument which is the thing to dispose and another which is the block to dispose it after:

  def using[S <% Disposable[S], T](what : S)(block : S => T) : T = {
    try {
    finally {

To those uninitiated in the ways of Scala, that first line can look a little scary, so let's look at it in more detail.

def using[S <% Disposable[S], T]

tells us that we are declaring a method called "using" which is parameterized on two type arguments: S, which must have a view of type Disposable[S], and T. Next,

(what : S)(block : S => T)

says that the method takes two arguments: "what" of type S (which we specified must be Disposable in the type constraint earlier) and a block which takes one of those S objects and returns a T. The fact that brackets, rather than a comma, separate the two arguments shows that the method is curried, i.e. it may be partially applied by its callers: this makes for some nicer code later on. The final T just tells us that the method returns something of type T.

Armed with this understanding, it should be very easy to see that the body of the function is statically safe and does just the same thing as the C# example I showed at the start of this post. That's all pretty neat! Let's see some of the code you might write using this function, assuming that the method definitions I've just given have been added to an object called Disposable which accompanies the trait of the same name:

import com.omegaprime.Disposable._

class Closable {

  def close() {

  def doSomething() {
    System.out.println("Doing something")

object Program {
  def main(args : Array[String]) {
    using (new Closable()) (closable => {

This will print:

Doing something

Lovely stuff! The sharp eyed reader will have noticed that the implicit conversions I defined above actually both apply for some objects (i.e. those which have both close and dispose methods): they might then be tempted to ask which conversion to Disposable gets used by the compiler for such an object. The answer for me is that it seems that the close method is always picked as the one to be called by Disposable.dispose, but I suspect this is an implementation detail, and will probably even vary from version to version: from the compilers perspective these two choices must be equally good.

I hope this article has gone some way to showing you some of the advanced features of Scala and how they can be used to solve real problems in software engineering. Note, however, that if you are going to play along at home you need at least version 2.6 of the language, as structural types were only added recently