Skip to main content
Ben Nadel at cf.Objective() 2010 (Minneapolis, MN) with: Doug Hughes and Ezra Parker and Dan Wilson and John Mason and Jason Dean and Luis Majano and Mark Mandel and Brian Kotek and Wil Genovese and Rob Brooks-Bilson and Andy Matthews and Simeon Bateman and Ray Camden and Chris Rockett and Joe Bernard and Dan Skaggs and Byron Raines and Barney Boisvert and Simon Free and Steve 'Cutter' Blades and Seth Bienek and Katie Bienek and Jeff Coughlin
Ben Nadel at cf.Objective() 2010 (Minneapolis, MN) with: Doug Hughes@doughughes ) , Ezra Parker , Dan Wilson@DanWilson ) , John Mason@john_mason_ ) , Jason Dean@JasonPDean ) , Luis Majano@lmajano ) , Mark Mandel@Neurotic ) , Brian Kotek , Wil Genovese@wilgeno ) , Rob Brooks-Bilson@styggiti ) , Andy Matthews@commadelimited ) , Simeon Bateman@simBateman ) , Ray Camden@cfjedimaster ) , Chris Rockett ( @RockettMan ) , Joe Bernard@JEBernard ) , Dan Skaggs@dskaggs ) , Byron Raines ( @byronraines ) , Barney Boisvert@barneyb ) , Simon Free@simonfree ) , Steve 'Cutter' Blades@cutterbl ) , Seth Bienek@sethbienek ) , Katie Bienek@KatieBienek ) , and Jeff Coughlin@jeffcoughlin )

Listen To Sean Corfield When It Comes To OnMissingMethod()

By on

I recently blogged about the new ColdFusion 8 OnMissingMethod() function that is available to ColdFusion components. I had assumed that it was meant for error handling and that my experiment to use OnMissingMethod() to handle non-existing functions was a silly, to-be-avoided misuse of the new functionality. Sean Corfield, the man who originally asked that this be added to the ColdFusion feature-set, informed me that it was quite the opposite; not only was this not ever meant for error handling, it was specifically added to allow ColdFusion components to handle Getter / Setter methods without ever having to write them.

So, please ignore my blog post and look forward to those by Sean Corfield; he says that he will be writing a good deal on OnMissingMethod() in the future.

Reader Comments


The best use is actually how he said it. Think things like: the programmer can define methods that do what they are supposed to just by the way they are named.

So you can have (an ActiveRecord example from Rails):


The method doesn't exist, but you define the handler to say something like:

if method_name starts with "find_by"
determine which columns to find by
perform the query with the given arguments

Last night, I was working on a script to let me create objects in a game. I wanted to do things like:

create_small_shiny_with_a_black_leather_hilt_weapon.named("Long Sword") do
damage_of(1.d6 + 2)

So I used method_missing to define a handler for when the method matches the pattern "create_\w*_weapon" to extract the description from the method name. This allows me to have a cleaner syntax for describing objects in the game.



It sounds good, and since it is not actually working via Exceptions, it should be fairly fast (minus the overhead of the missing method name evaluation). I am, however, not used to to even coding with Getters / Setters (due to my caveman brain) and look forward to Sean explaining what the best practices are for something like this.


Actually, onMissingMethod has no overhead (apart from any processing you do inside it) compared to a standard method.

So go nuts! :)


I have mixed emotions regarding using onMissingMethod vs. a code generator and actually creating getter/setter methods. The biggest drawback I see is that you lose the introspective self-documenting aspect. Dump a CFC and you can see all of the methods available. Do a getMetaData and you can walk the list and do your own documentation routines.

Without the code, you're more in the dark. Is it getCustomerNumber() or getCustomerID()?Is it getArticleName() or getArticleTitle()?

Or do I need to write a documentation function that checks the field list and generates virtual documentation for virtual functions?



I suspect that that is going to be the biggest concern people express for this sort of programming. This type of set up is going to make documentation an essential part of the developer's life (both the developer of such components as well the user). The foggiest area for this, I think, is going to be in a Peter Bell type situation where he might have some base iterating business object (IBO) whose job it is to handle these generic getter / setter methods for composed objects. In that case, documentation would be near impossible as the IBO component you need to use might not even be tied directly to the ultimate functionality. In that case, you would need to know what object is being composed and have its documentation!


@Michael, Ben:

I don't share the concern. A static code generator simply doesn't have the ability to generate the same kinds of methods as I've given examples for above.

In the ActiveRecord example above, I suppose technically it could generate every combination of columns for every combination of and/or and in every possible order.

Even given that possibility, do you really want it to? That would clutter your interface and make everything else (the important stuff) hard to find. I'd rather manually add a line to my documentation that says "methods such a find_by_column1_and_column2 are available."

In the second example, there is simply no way you could generate it, aside from the give enough monkeys enough time and they'll write Shakespeare quality plays. Or in other words, generate every combination of characters into words in the English language and in any order...

I don't think such brute force is a feasible solution to either problem. Much better to dynamically generate the missing method.



I am in no position to argue for or against dynamic method handling as I really have not experience with this. I guess, the point is that leveraging the dynamic stuff is great, so long as there is documentation about how it can / should be used.