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.

If you liked this post, subscribe to my free full RSS feed.
Filed under: Java, Rails, Ruby

You can share this post!
Do you want to tell others about this article? Use the social bookmark icons to submit this artice to the service of your choice. Thanks.

Get free updates by email

If you did like this article you can get free updates with your RSS reader, you can follow me on Twitter or get free update to new posts by email. Enter your email:

 
About the author: Stephan has been working as a head of development and CTO. He has experiences in different technologies since 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.

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