Question

I’ve seen several Scala questions recently (e.g. here, here, and here) that called for the use of proxies, and it’s come up more than once in my own work. The Scala library has a number of proxy traits (14, if I counted correctly).

Proxy classes/traits usually contain lots of boilerplate:

class FooProxy(val self: Foo) extends Foo {
   // added behavior
   def mymethod = ...

   // forwarding methods
   def method1 = self.method1
   def method2(arg: String) = self.method2(arg)
   ...
}

trait Foo {
   def method1: Unit
   def method2(arg: String): Unit
}

My first thought was to define a Proxy[T] trait that could be used as follows:

class FooProxy(val self: Foo) extends Proxy[Foo] {
   // added behavior
   def mymethod = ...
}

where trait Proxy[T] extends T. Of course, it’s not actually possible to define the Proxy trait without compiler magic.

My next thought was to look for a compiler plugin (such a capability clearly isn’t in the existing compiler, or the sources for those 14 proxy traits would be much smaller). Sure enough, I found Kevin Wright’s AutoProxy plugin. The plugin is intended to solve the proxy issue neatly, along with other use cases (including dynamic mixins):

class FooProxy(@proxy val self: Foo) { ... }

Unfortunately, it looks like work on it stalled in November (2009). So, my questions are

1. Is there continuing work on the AutoProxy plugin?
2. Will this find its way into the compiler?
3. Are any other approaches being considered?
4. Finally, does this point to a significant weakness in Scala? After all, wouldn’t it be possible to define a Proxy trait given lisp-style macros?

Answer 1

Four questions, four answers

1. I am, though family has to come first! Plus others are involved in looking at the general issue with synthesizing methods in a compiler plugin.

2. If so, it will most likely be in a different form, perhaps without using annotations.

3. I don’t know of any equivalent plugins, although one of the Scala GSOC candidate projects was based partly on my autoproxy code. There is, however, one very clean solution that will work in most cases and doesn’t need a compiler plugin at all: You define an implicit conversion from FooProxy to Foo that simply returns the self member; this will get you most of the way there. The main issues with the approach are that it’ll make life harder if you need to use your code from Java, it may be less efficient in terms of speed/memory, and it’s another imlicit that you have to be aware of.

4. The frustrating part is that almost all of the necessary logic is already available in the compiler, and it’s used for mixins, so there really should be an elegant way of handling the task.