Friday, April 25, 2008

XOR vs Equality Operators (^ vs !=)

A while ago, I committed code to my client's code-base that reads like this:

public boolean isSomethingValid() {
  return !a ^ b;
}

At the end of the day, Nick Malnick came to me and mentioned that a discussion broke out in his room because "someone used an XOR!" I went to the room to see what the matter was, and apparently another programmer who encountered that statement rushed to others for help because he didn't know what to make of the ^ operator and didn't know it was even a part of the Java syntax.

As Nick and I were leaving home, we had a talk about it, and I realized that I could have achieved exactly the same effect by writing the following instead:

public boolean isSomethingValid() {
  return a == b;
}

In fact, we discovered the following equivalence relationships:

 a ^ b <=> a != b
!a ^ b <=> a == b

Given these relationships, we had further discussion about whether it's a good idea at all to use the XOR operator in our client's code-base given that the developers rarely ever use it and aren't accustomed to it.

So, again in the spirit of the past blog post If-Else vs Direct Return and Manuel's blog post If Then (If Then Else) Else (If Then Else), I'd like to know the public's opinion on the matter.

Would you use XOR or equality operators? Does the decision possibly depend on the context? In other words, do the equality operators make more sense in some situations and XOR make more sense in others? If so, what are the different situations that warrant the use of each?

Saturday, April 12, 2008

Template Method Design Pattern in Ruby

One of the Gang of Four Design Patterns that benefit quite a bit from static typing in Java is Template Method.

You have an abstract class like this:

public abstract class Template {
  public void templateMethod() {
    performStep1();
    performStep2();
    //do some extra work
  }
  protected abstract void performStep1();
  protected abstract void performStep2();
}

And then a concrete implementation:

public class Implementation extends Template {
  protected void performStep1() {
    //implementation goes here
  }
  public void performStep2() {
    //implementation goes here
  }
}

The nice thing with the Eclipse IDE is that the moment you make the Implementation class extend the abstract Template class, the Java Editor immediately notifies you of the missing implementations of the hook methods (performStep1() and performStep2()) so that you go ahead and implement them. In other words, having the step methods abstract provides us with a guiding API that helps developers figure out what to implement.

During development of Glimmer, I wanted to use the Template Method pattern for something. As I started to implement it, I remembered that there are no abstract methods in Ruby because you cannot have a compiler check that you implemented all abstract methods due to Ruby being an interpreted language.

When writing Ruby programs test-first however, not having a compiler is not a problem since compilation is really just a tiny part of proving that a program is correct. In reality, unit and integration tests are what truly give the confidence that a program works anyways. Also, while a compiler is useful in providing quick feedback about errors if a developer was testing the program functionally through the user-interface, tests provide feedback that is almost as fast, so with a language that requires much less keystrokes like Ruby, you end up with higher productivity gains in the end even without the benefit of compilation.

Here is how template method was implemented in Ruby:

class Template
  def template_method
    perform_step1;
    perform_step2;
    #do some extra work
  end
  def perform_step1
    raise "must be implemented by a class"
  end
  def perform_step2
    raise "must be implemented by a class"
  end
end

class Implementation < Template
  def perform_step1
    #implementation goes here
  end
  def perform_step2
    #implementation goes here
  end
end

So when writing a class that extends Template, if either of perform_step1 or perform_step2 was not implemented, you get an exception right away when running template_method. Of course, with test-driven development you have assertions, which will be better indicators of whether you implemented things correctly.

Still, in Ruby, you can have an alternative Template Method implementation by relying on blocks:

class TemplateImplementation
  def template_method(step1, step2)
    step1.call;
    step2.call;
    #do some extra work
  end
end

It is used as follows:

implementation = TemplateImplementation.new
implementation.template_method(
  lambda {print "Hello"},
  lambda {print "World"}
)

This way, you can pass the hook methods performStep1 and performStep2 as anonymous function blocks, which can be created in Ruby using the lambda keyword (a shortcut for Proc.new.) Lambda produces Proc objects, which can be easily executed by calling the call method on them.

In conclusion, while Template Method in Ruby misses the benefit of static typing, it can yield shorter more concise code, especially by relying on blocks, and it can still be implemented correctly by following test-driven development.

Sunday, April 06, 2008

If-Else vs Direct Return

The other day I was pair-programming with a colleague at my client's site, and after we had a newly written unit-test fail, the implementation that my colleague wrote was something like this:

public boolean isConsumable() {
  if (STATUS_NEW.equals(getStatus())) {
    return true;
  } else {
    return false;
  }
}

After the test passed, I went ahead and did a refactoring by turning the method into:

public boolean isConsumable() {
  return STATUS_NEW.equals(getStatus());
}

The test passed again. However, my colleague wasn't happy with that implementation. I was taken aback because I thought since it was shorter, that meant we had less code to maintain. But, my colleague expressed that he found it more understandable as an English-statement to say something like:

if a.equals(b) return true else return false

instead of

return a.equals(b)

The first time I personally learned the ternary expression "condition ? true-result : false-result", I found it a mind-bender and preferred to use traditional If-Else statements instead. After a while, I got used to the ternary expression and it became a basic construct in my thinking. In the same token, right now whenever I read a line like "return a.equals(b)" under a boolean method, I quickly translate it in my mind to something like: method value is determined by equality of a to b. Therefore, I believe it is just a matter of habbit and getting used to the shorter syntax.

Still, I am curious to know other people's perspectives on this. Which syntax do you prefer and why (If-Else statement or shorter direct return statement)?

Thursday, April 03, 2008

Glimmer Eclipse Project Creation Review

You've heard about Glimmer:
http://www.infoq.com/news/2008/02/glimmer-jruby-swt
http://andymaleh.blogspot.com/2007/11/glimmering-philosophy.html
http://andymaleh.blogspot.com/2007/12/listeners-in-glimmer.html
http://andymaleh.blogspot.com/2007/12/glimmers-built-in-data-binding-syntax.html
http://andymaleh.blogspot.com/2008/02/table-data-binding-and-mvp-in-glimmer.html

shell {
  text "JRuby on SWT"
  composite {
    label {
      text "Hello World!"
    }
  }
}

You've seen Glimmer in action at EclipseCon 2008:
http://andymaleh.blogspot.com/2008/03/glimmer-at-eclipsecon-2008.html
http://andymaleh.blogspot.com/2008/04/first-glimmer-game.html



And finally, Glimmer is proposed as an Eclipse Technology Project with the Creation Review scheduled on Wed, 16 Apr 2008 at 1600 UTC:
http://www.eclipse.org/proposals/glimmer/

If you appreciate the ideas behind Glimmer, and would like to see it grow, or would like to become a part of the project by contributing your own ideas or code, feel free to express your interest by joining the Creation Review call-in meeting on April 16th at 11AM CT (GMT -06:00).

I will be presenting some slides to review the purpose of Glimmer, where it is now, and where it is going in the future.

Wednesday, April 02, 2008

Eclipse Regional Communities, Chicago Edition

Yes, if you're not living close to Austin, you can come to Chicago instead. ;)

Please click >>here<< to sign up for the Chicago Eclipse Community mailing list.

We are open to any event ideas. For now, it seems like the first two events will be an Eclipse DemoCamp where participants get 5-10 minutes each to demo local Eclipse projects, and an Eclipse Ganymede overview.

We'll keep you posted. Otherwise, hang on in Chicago's windy weather!

Tuesday, April 01, 2008

First Glimmer Game

Nick Malnick and I programmed the first game to utilize the Glimmer engine. We did so by writing tests first and following the model-view-presenter pattern with data-binding.

It is a simple 2-player Tic Tac Toe game that I demonstrated during my talk at EclipseCon 2008:



I finally committed the completed version to SVN. For those interested in looking at the code, feel free to do so by clicking on these links:Notice how easy it is to create a 3x3 grid in Ruby by relying on (1..3).each iterator statements and blocks. Also, notice how simple it is to data-bind and add listeners using the Glimmer bind keyword and on_[action] syntax.

Of course, a big part of the reason why I like Glimmer for building desktop applications is to have the ability to write very concise domain model code in Ruby. Check out the TicTacToeBoard and TicTacToeBox classes for examples of very readable and easy-to-maintain domain model code, especially in comparison to the often bloated setter/getter infested Java domain models.