Lambda the Ultimate

I agree that the questions from the audience were a bit distracting, particularly since it was so hard to hear them with all the ambient noise.

One question that a member of the audience had was in regard to Martin's claim that traditional OO language support doesn't go far enough to enable components. He said that interfaces allow you to specify the services a component provides, but not what a component requires. His answer seemed to handwave a bit; I'm still uncertain.

Say we define a class C whose constructor takes a parameter with interface R and implements the interface I. In other words, in Java-ese:

class C implements I { public C(R r) { ... } }

If we declare "C" to be a component, it seems to me that the interface "R" specifies the services the component requires, and "I" specifies the services it provides. If we think of both "R" and "C" as modules, this seems to be close to the idea of functors, with the exception that (in Java, at least), I and R cannot specify types.

What is it about "components" that requires more of the language than this? I'm guessing the abstract types have something to do with it, but I still don't quite get it.

I really enjoyed this video. Kudos to Martin and his team for a valiant effort at unifying OO and FP, and breaking new ground in the process.

I haven't watched the video yet, so don't know how well Odersky addressed the question in the talk. But you're right in guessing that there's a bit more to Scala's support for components than Java-style interfaces, and you're right that abstract types have something to do with it. I highly recommend Scalable Component Abstractions. I think you'll find the presentation clear and the examples quite compelling.

Let me take a quick stab at giving you an intuition as to how Scala provides support for specifying a component's required interface:

When you specify a class, you may also specify the type of the this variable using the requires keyword (when you don't specify it, it's simply the defining class itself.)

So, suppose you have a component MessageBroker, that depends on a Transport component, you may specify it like this:

class MessageBroker requires (MessageBroker with Transport)

The effect of this definition is that this will be of the compound type MessageBroker with Transport in the body of MessageBroker.

This is similar to directly extending a concrete implementation of Transport, in that members from Transport will be available on this in your message broker. However, it is more flexible than inheritance, as it allows you to defer the choice of which concrete Transport you want until you actually instantiate MessageBroker. In other words, Transport need not be a concrete class (so you can use abstract type members to make this even more flexible).

So, to instantiate a MessageBroker with a HTTPTransport, you write new MessageBroker with HTTPTransport.

It's true, class constructors can express required components as interface-typed parameters. However, this runs into problems for more complex compositions.

One problem is that diamond dependencies cannot be expressed. I.e. class A requires B and C, but also requires that B and C agree on the type of one of their components. This problem is solved by abstract types in Scala and by sharing constraints in ML.

Another problem is that recursive dependencies cannot be expressed through parameterization. This problem is also present in the SML module system. It is solved in Scala through mixin composition.