Tuesday, August 29, 2006

Filling in the Java closure gap

The interesting FuntionalJ library fills in a gap with reflective function objects while waiting for JDK7 closures. With flavors of C++ functors and Python zip and tuples, FuntionalJ is a gem.

3 comments:

Anonymous said...

Looks to be very interesting.

One comment; the function definitions look to take a class parameter, and string parameter representing the function to be called.

Wouldn't this cause all kinds of refactoring headaches? If the function name changes, I don't see this generating any warnings.

Am I missing something with how reflection works?

Brian Oxley said...

This is always a problem with reflection. However most current refactoring environments (e.g., IDEA, Eclipse, etc.) have help for finding method and class name strings for refactoring.

This is an even more widespread problem for dynamic languages (Smalltalk, Ruby, Perl, et al), but it was on Smalltalk that the first refactoring IDEs were invented, so it is clearly surmountable.

One of the best guards against refactoring errors in the face of reflection (or dynamic languages) is unit testing. Before refactoring, make sure you have test coverage to detect broken method names in the functionals.

Anonymous said...

Yes, unit testing would/should catch this.

What would be irksome for me is that I wouldn't be able to search for all calls to a particular function. As well, you'd lose auto-completion functionality (ctrl-space in Eclipse).

Anyways, looks cool.