Object Commando languages, development and design


Clojure Protocols Part 1

Stale code warning

There have been small changes to the protocols code in Clojure. The below post is still useful, but a few details of the example code is different. See part 3 for the updated syntax.

Clojure Protocols

Protocols are a new feature in Clojure, set to be released in the next version. They provide polymorphism in a very Clojure-ish way. I think it's a great lightweight polymorphism implementation that has a lot of potential. In true Clojure style I think it meets the polymorphism objective and yet doesn't need to totally change the way you already write your code in Clojure. I'm breaking this entry into more than one piece to show some different ways that Clojure protocols can be used. Because it's so new, there are not a lot of docs out there on it, but Rich does some good documentation on the macros themselves. If you want to try these examples, make sure you're running off of the 1.2 version of Clojure (from Clojars or a local build from the Clojure git repo). First I'll start by defining a simple protocol:

(defprotocol TextOutput
	  (output-string [x string]))

In Java terms, I'm defining a TextOutput interface (actually a Java interface is being created, but more on that later), that has a single function named output-string that includes no implementation details. The input to this function is a little tricky though. I specified a parameter x and another one called string. The first parameter will be used to pass the implementation of the interface into the function. You don't need to write code to handle the parameter x and when you write your implementation, you'll act like it doesn't exist. A wiki type text output of an italics string would look like:

(deftype ItalicsOutput [] TextOutput
	       (output-string [string] (str "_" string "_")))

I have begun thinking about this in Java terms as a class ItalicsOutput that implements the TextOutput interface. Here in the output-string function, I only specify one parameter (not two). Next you can use this implementation with the following code:

(output-string (ItalicsOutput) "stuff")

I'm telling Clojure I want it to execute the output-string function, on the implementation (ItalicsOutput) (more in this below) with the argument "stuff". I think that below is a little more readable:

(def italics-impl (ItalicsOutput))
(output-string italics-impl "stuff")

Which just assigns the instantiated implementation to a variable which can then be used. These implementations can also have parameters, like:

(deftype PrefixedOutput [prefix-string] TextOutput
	       (output-string [string] (str prefix-string " " string)))

I think passing a variable in makes the instantiation step make a little more sense:

(def prefix-with-more (PrefixedOutput "more"))
(output-string prefix-with-more "stuff")
"more stuff"

Both implementations can be used together as well:

(defn print-all []
	(let [italics-impl (ItalicsOutput)
	     prefix-with-more (PrefixedOutput "more")]
	     (println (output-string italics-impl "stuff"))
	     (println (output-string prefix-with-more "stuff"))))

With output that would look like:

more stuff
Comments (3) Trackbacks (1)
  1. Ugh… This makes me think of Python’s horrible self keyword, which makes you declare methods with n parameters (with self as the first parameter) but forces you to call them with n-1 parameters (without self).

    Looks very hackish.

  2. @Steve
    maybe, but that’s why you have macros in clojure, you can wrap it up in whatever syntax suits your fancy, unlike in python.

  3. Steve said “…which makes you declare methods with n parameters (with self as the first parameter) but forces you to call them with n-1 parameters (without self).”

    With clojure protocols you declare methods with n parameters (with self as the first parameter) *and* call then with n parameters (with self as the first parameter). So it’s consistent.

    Passing ‘self’ as the first parameter may seem weird coming from OO languages – that’s a matter of taste. LISPs don’t have many special forms – everything is a list literal, or a reader macro that evaluates to a list literal. This may seem less expressive, as for example you can’t easily create a ‘.’ style notation for method calls. On the other hand this consistency enables macros, which allow you to create custom syntax, as polyplus74 pointed out.

    Pick your poison – lot’s of ‘expressive’ special forms, or simplicity, consistency and power. In any case, it’s not ‘hackish’.

    (another) Steve

Leave a comment