Code Monkeyism

Programming is hard by Stephan Schmidt

June 13, 2008

Another Rails and dynamic language fallacy concerning missing methods

Russell writes in the post The Dynamic Language Advantage: A Concrete Example:

“All you have to do is make the call to the non-existent method that contains your column names and Rails will dynamically generate the method for you.”

Though he got quite some flak for his opinion.

@cards = Card.find_all_by_cardType_and_expirationData(cardTypeId, expirationDate)

Which looks magic to most people and most impressive. But in the end it’s not more safe or magic than

Card.find("all_by_cardType_and_expirationData", cardTypeId, expirationDate);

This code can easily be written in any static language, becasuse the method missing property is no more safe or expressive than a String. The idea that parsing a method name from method missing is different than parsing a String in this case is a fallacy. I wonder why not more people use Strings like this to create finders? Perhaps because it’s not a good idea, as some comments in the mentioned post claim?

Thanks for listening.

About the author: Stephan Schmidt is currently a team manager at ImmobilienScout24 in Berlin. Stephan has been working as a head of development and CTO. He has used a lot of different technologies in the last 20 years including Java, Rails and Python. Stephans main field of interest is maintainablity and productivity in software development. Want to know more? All views are only his own.

If you did like this article but you don't want to subscribe to new articles with your reader, you can follow me on Twitter or subscribe to new posts with your email:

Comments

Fabrizio Giudici

I’d like to point out that the Parancoe framework (http://www.parancoe.org, go to http://www.parancoe.org/articles/2007/08/28/how-to-add-finder-methods-to-parancoe-daos/ for a specific example) allows you to define an interface with a statically declared method findAllByCardTypeAndExpirationData() and it gets implemented by dynamic generation of code. To me it’s the best approach if you like expressive method names, compiler safety and would like to avoid boilerplate code.

June 13th, 2008
stephan

@Fabrizio: Yes, this the way I think is a good idea. Especially when the system creates a prepared statement.

June 13th, 2008
Lucio Benfante

In fact Parancoe is doing better than a prepared statement: it’s using pre-compiled (at application bootstrap/deploy time) named queries.

June 13th, 2008
stephan

@Lucio: Is it possible to just use Parancoe daos (for JPA) without anything else?

June 13th, 2008
Lucio Benfante

Yes, it’s possible. It’s in the parancoe-core module. At present there is a limitation on the JPA implementation to use: it must be Hibernate. In parancoe-core the most part is the persistence DAO feature. Another interesting part is the support to unit-testing the persistence-related code.

I know a person that is using parancoe-core in a Swing application.

I’m working our next release of Parancoe (2.0), an I’m evaluating to isolate the DAO feature in a specific module with minimal dependencies.

June 13th, 2008

Leave a Reply