opencomponentry

Well well well..With some free time on my hands and a couple google searches later I’ve stumbled upon the roots of this whole “closures” debate fiasco.

Warning: I have nothing but respect for the people I am about to reference, and am probably slightly out of my league in discussing these features - but the debate seems so pointless and obvious that it deserves at least a quick note.

The debate seems to focus around this and this. The summary result of which was described well in Neal’s latest blog post example code snippets of the two:

/**
 * An object with a function accepting pairs of objects, one of
 * type T and one of type U, returning those of type V
 */
interface Combiner<T,U,V> {
  V combine(T t, U u);
}
class ParallelArray<T> {
  /**
   * Returns a ParallelArray containing results of applying
   * combine(thisElement, otherElement) for each element.
   */
  <U,V> ParallelArray<V> combine(
    ParallelArray<U> other,
    Combiner<? super T, ? super U, ? extends V> combiner) { ... }
}

vs this:

class ParallelArray<T> {
  /**
   * Returns a ParallelArray containing results of applying
   * combine(thisElement, otherElement) for each element.
   */
  <U,V> ParallelArray<V> combine(
    ParallelArray<U> other,
    { T, U => V } combiner) { ... }
}

You’ll notice in one definition we are forced to create a new type to represent the “closure”, while in the other the type information is bound using this new type syntax of “T, U => V”. Someone actually put this example up during a presentation and asked which people would prefer to see with a straight face.

So, the first solution is a watered down version of anonymous inner classes that sets out to provide closure-like functionality without hurting developers with new programming concepts - ie ” no new concepts to learn, just a more concise syntax for something they already do”.

I think there are lots of things that could be classified as bad in the first example. Let’s start a list:

• It isn’t a closure. (that tends to make things harder when trying to propose something that doesn’t qualify as the definition of the thing it is proposing to do)
• I’d argue that it actually does the opposite of what it strives to do - adds more confusion. Why do we need to define a new type for the thing we were trying to define in an interface already? How the hell does that make sense to people?
• It’s irresponsible. The definition of closures has been pretty well established in the programming community already, how are people going to carry that knowledge over to this new feature? What are our dynamic language friends going to say when they see us typing up our vs. 1 closures? They’re going to make fun of us is what they will do. Because it isn’t a closure and everyone knows it. One more nail in the coffin for the language. It’s embarassing.

I’ll admit that there are probably lots of pragmatic implementation concerns surrounding how hard it will be to implement the second version in the jdk - but it seems like with something as important as a language level feature the old saying “if you aren’t going to do something right, don’t do it at all” really applies. At least if your interest is in furthering the shelf life of this language and not applying a quick band aid that will quickly peel off at the first sign of water/trouble.