Just a Thought...: Judicious Use of Closures

Judicious Use of Closures

Berin Loritsch — Sun, 22 Jul 2007 00:00:00 +0000

After going back and reviewing some of my old articles, I got to thinking that my role based authorization system I outlined in this article still reflected my Java bias. I know some people approach new toys and technologies by diving in head first, and then backing off later. I personally try to think of what problems that approach can practically solve. As a result I may be a late bloomer, but the flowers are nicer.

The whole issue of why I thought it could be better is because it is still too Java/C++ based. I tried to make it more rubyesque but I stopped short. You see, in the Java/C++/C# world you think about having to query an object and then do something. This is in stark contrast to the Smalltalk and Ruby approach where you tell an object to do something for you. You can even pass in some extra steps so that you can be very happy. So what’s the difference, and does it really make a big deal? The difference is subtle, but so is elegance. Let’s consider the code I had you write to do work if a user had a particular role:

if @user.is_in_role? (:Admin)
  Article.find(params[:id]).destroy
  flash[:notice] = 'Article was successfully deleted.'
end

The “is_in_role?” message is straight from Java’s HttpServletRequest interface. It does make sense from a certain point of view, but the control is inverted from what it should be. In short, we should tell the user to do something if they have a roll. Here’s how the same logic should look from the subtle shift in viewpoint:

@user.with_role :Admin do
  Article.find(params[:id]).destroy
  flash[:notice] = 'Article was successfully deleted.'
end

So what’s the big deal? They both do the same thing, and they are both pretty readable. The big fat hairy deal is in perspective. The first version is interrogative, we are treating the user object like a little child and taking back control. We aren’t letting the user object do his part of the chores. The the second version is imperative, we are telling the user object what we need him to do. We trust him to make judgments like whether he can do it or not. The implementation of the method is just about the same under the covers, but the important thing to stress is who is doing what. We should provide general directions, and the objects should pull their own weight to make it happen.

Ruby is really great when it comes to closures. Every method implicitly handle closures. The trick is the yield keyword. If you want to pass a parameter to the closure, just add it on to the yield command. Here is how our implementation would look if we did the more rubyesque approach:

def with_role role
  if roles.include? Role[role]
    yield
  end
end

That’s pretty slick when you think about it. You can make any method handle closures just by using the yield command. If we needed to pass parameters, we just tack them on after the yield command. There’s tons of applications for it, but it’s best to start off slow. After you add support for a closure to an object’s method, ask yourself if it makes life better. Is the code that matters more readable? Does it simplify life? The answers to those questions will help you walk the balance between elegant and gimmicky.

Contrast Ruby With Java

I’m cheating a little bit with referencing the current specification proposal for JSR for Closures in Java as it represents the closest thing to what you can expect here. First of all, if you use Ruby or Smalltalk you will be sorely disappointed. In a sense, Java closures still follow the same pattern in that the closure is an object—only you have to be explicit about it. Edit: Apparently I missed a very important, and good part of the new Java closure spec. I’m changing the code examples to reflect the preferred method.

First, let’s look at the Java way of solving the problem we solved with Ruby:

if ( user.isInRole("Admin") ) {
    Article.find(id).destroy();
    sendMessage( "Article was successfully deleted." );
}

It’s fairly readable, and it doesn’t look too bad. Again, we are treating the user object like a little child. We are asking the object about itself and assuming control. The approach has its roots in the procedural world that the C based languages came from. Now let’s look at what the new Java Closures will look like, and whether that will help things be more readable.

user.withRole("Admin") {
    Article.find(id).destroy();
    sendMessage( "Article was successfully deleted." );
}

There is an uglier way of declaring the closure, but since we want the code to be as elegant as possible I chose this form. Before I go into details of what is going on under the hood, we need to see the other half of the equation so we can better understand what’s going on. Here’s the implementation of the withRole method:

public void withRole(String role, {=>void} block) {
    if ( roles.contains( role ) ) {
        block.invoke();
    }
}

Under the covers, the definition of the closure is the ugly {=>void} block. That’s telling the compiler to create an anonymous interface that has a method named invoke with no parameters and returns a void. Ok, time to take a breath. If we want to add parameters to the invoke method, we have to add them as a comma separated list in front of the => symbol. The void after the symbol is the return type. The implementation of this anonymous interface is assigned to the variable name block. There’s a bit more to it, and you can reference variables declared outside the block—but for the purposes of our conversation let’s keep it simple.

When we pass in our implementation, we use the same basic construct except we add variable names to the parameters and the implementation after the ugly symbol. We cheated in our example by not having any parameters. You might think that because the method tells what types the variables are you could skip the type declaration. You’d be dead wrong. Consider the example the spec provides (granted this is from the original specs:

// Define it
{int,int=>int} math;

// Assign it
math = {int x, int y =>
    return x + y;
};

// Invoke it
assert 2 == math.invoke(1, 1);

Edit: I had to revise my initial reactions based on the input from commenters. The Java spec has come a long way. Although it’s not perfect (and what in life is?), it is a vast improvement over what we once had. The critical part of Java closures is that they are really closures. That means that you can reference variables declared outside the closure (you can’t do that with anonymous inner classes), and they enable more flexible, robust, and readable code. At least on the calling side of things. Java will never match the simplicity and elegance of Ruby, but this time it will be much improved.

The Languages Are Different, Play to Their Strengths

What I don’t want you to do is walk away with the impression that Ruby is great and Java sucks. I work with both technologies, one because I want to and the other because I’m paid to. They both have their strengths, design idioms, and code aesthetic. The important thing is to play up the strengths of the language you are using.

Just because a solution is elegant in one language doesn’t mean the same approach translates well to another. Sometimes it’s just plain impossible. Other times, the overall approach is fantastic, but the implementation will have to have subtle differences based on the language you are using. That’s OK too. My Java ActionPack is based on most of the design principles of Ruby’s action-pack (part of Rails), but they are done in a very Java way. They evolved differently, appealing to what is considered elegant and good code for the respective languages they are written for.

Edit: It appears that there are quite a few things I don’t quite get about the Java closure spec. Until we have something solid to play with, everything said is academics. Neal Grafter is the headmaster for the spec, and he should know better than I about what can and can’t be done with it.

"Judicious Use of Closures" by Ricky Clarkson

Mon, 23 Jul 2007 07:05:09 +0000

Java’s original designers were wrong about operator overloading, maybe on purpose - one of the big selling points was that the hard things about C++ weren’t present in Java - and operator overloading were a big pain point of C++, at least in theory.

In practice, there are better operator overloading syntaxes than C++’s, and they don’t make things harder to read, unless you use them in a hard to read way. x.add(y) could easily format your hard drive - there’s no advantage to x.add(y) over x+y.

I don’t like using the control invocation syntax in a non-void context. I’d rather use the other syntax to implement a closure that acts as a Comparator.

My own vote, not that I have one, is for ‘return’ to return from the enclosing method in the control invocation syntax, and to return from the closure in the normal syntax. In other words:

int x()
{
    blah()
    {
        return 5;  //returns from x()
    }
}

whereas:

void x()
{
    plus={int x,int y => return x+y}; //plus.invoke(2,3) returns 5.
}

In the latter case, I’d have return x+y (without a semicolon) mean the same as return x+y;, and the same as x+y. Another possibility is just to ban returns from within that kind of closure.

Neal justifies the approach by saying that the current Java way is broken, and that we shouldn’t add new broken syntax, and I agree, but I just can’t justify having x+y and return x+y have different meanings based on that. For Neal’s reasoning, see: http://gafter.blogspot.com/2006/08/tennents-correspondence-principle-and.html

"Judicious Use of Closures" by Berin Loritsch

Mon, 23 Jul 2007 01:57:05 +0000

Neal, It appears there is much I don’t understand about the way Java plans on doing closures. I think the biggest issue is going to be the education of users. I’d like to think I’m a pretty smart guy, and if I’m having this kind of trouble understanding what syntax is being used where, that’s a problem. Without a compiler to turn this theory into practice, it’s really all academic anyway.

"Judicious Use of Closures" by Berin Loritsch

Mon, 23 Jul 2007 01:47:57 +0000

If the {int x, int y => x+y} format is the case, that gets us closer to Ruby. I can see where the source of contention would come from. In Ruby and Smalltalk (and I think Lisp/Scheme) the last statement in a block is the return value–but in Java we have been told to be explicit with everything every where. There is a cultural and cognitive clash going on there. In a sense, for consistency within Java it might be better to have the @return@ syntax.

As to your latter example, I think it might change too much at once within Java to allow that. The idiom in Java is to use Comparators and let objects that implement Comparable have a natural order. The creators of Java believed wholeheartedly that you shouldn’t allow operator overloading, which also means that operators are not methods, and only exist for primitive types. You just couldn’t pass in those methods because they wouldn’t exist.

I think the closest you would be able to come with Java would be something like this:

Collections.sort(MyObject a, MyObject b: list) { /* return */ a.getId().compareTo(b.getId()) }

I’ll leave the return as it is for now, until the shakedown is done.

"Judicious Use of Closures" by Neal Gafter

Mon, 23 Jul 2007 01:36:02 +0000

You wrote “A change in the current spec allows you to rewrite the above a bit differently:”… but that is all wrong. The control invocation syntax is for invoking a method that receives a closure, not for writing an assignment to a variable or for writing a closure expression.

As Ricky pointed out, the “return” statement is not how one yields a result from a closure. Rather, the return statement returns from the enclosing method, as it does in Ruby.

"Judicious Use of Closures" by Ricky Clarkson

Sun, 22 Jul 2007 22:08:24 +0000

I think there’s another mistake - {int x,int y => return x+y; } - return will return from the surrounding context, not from the closure (yes, this is a point of contention). {int x,int y => x+y} is more like it.

If Java also gained a method reference syntax, say, #’methodName(int) (rather like Common Lisp), we could potentially apply the same syntax to replace the whole of {int x,int y => x+y} with #’+, or {+}, or whatever the syntax actually was. I think that’d be good. Example:

Collections.sort(list,’#<); (sorts a list using < as the comparator)

Essentially, what I like in languages is uniformity - where you don’t have to do things like surround an operator in an anonymous class to pass it as an operand. Scheme seems to be the best at that out of the languages I’ve seen (it doesn’t even need the #’ syntax). The above sorting example would be:

(sort list <)

"Judicious Use of Closures" by Berin Loritsch

Sun, 22 Jul 2007 19:29:28 +0000

I’ve edited the Java portion of the entry, as the alternative syntax really does make a difference. Thanks for your comments, it helped me to understand the spec a little better.

"Judicious Use of Closures" by Berin Loritsch

Sun, 22 Jul 2007 18:53:03 +0000

I couldn’t figure out from the spec (which suffers from specifese) that there was the alternate invocation syntax. The alternate syntax specification makes this a palatable solution in Java. I’ll keep that in mind when I provide a finite state machine example where closures would be prefect.

I’m really happy that Java Closures is moving in this direction. It makes it feel like a first class citizen, and almost has me salivating for whenever they come. Hopefully it is soon.

"Judicious Use of Closures" by Neal Gafter

Sun, 22 Jul 2007 18:10:36 +0000

Besides the point that Ricky made (you chose to use the ugliest syntax possible for the invocation of withRole), you appear to be missing one of the greatest benefits of closures over anonymous inner classes. See http://www.parleys.com/display/PARLEYS/Closures%20for%20Java

"Judicious Use of Closures" by Ricky Clarkson

Sun, 22 Jul 2007 13:17:08 +0000

You missed a bit of the closures spec, namely the control invocation syntax:

user.withRole("Admin")
{
    Article.find(id).destroy();
    sendMessage( "Article was successfully deleted." );
}