commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arnd Kohrs <>
Subject [functor] some thoughts
Date Thu, 13 Mar 2003 11:39:02 GMT

Hi List, 
Hi Rodney,

thanks for publishing your functor code on jakarta.  

I am very interested in this stuff.  For one I noticed that in our own
development there have been several independent rudimentary starts of
functor frameworks.  Therefore a standard implementation would be very

I guess you are already aware of the article (may be it was even you who posted
it on the commons-dev list).  It is very inspiring, so I tend somehow to
the ideas presented.

I think there are some very interesting concepts in BlocksForJava which
would be nice to have as well in funtor.

- functors are very often defined (in my experience) as anonymous
  inner classes, therefore it would be nice if the to be implemented
  methodname is as short as possible for not compromising the
  readability of the code.  I would suggest "eval()" instead "evaluate()",
  "is()" instead of "test()" and "run()" is already short.

- IMHO "Predicate.test()" is (in a world of JUnit testers) a bit
  misleading, since "test" has overloaded semantics.  I like "is()".

- Is it necessary to include "toString()" and "equals()" in the
  interface definitions?  Since the functors does not rely the fact that
  these methods are overridden and there are no new semantics to these
  methods, IMHO they should be dropped from the interfaces.  That would
  also improve the focus of the javadoc.

I would not recommend that interfaces are changed in an advanced
project, however since this one is only several weeks old, IMHO there is
still some possibilities for drastic changes (ignoring star fleet
regulations ;-).  I realize that it hurts to rename the interface
methods, but in the long run when functors become a central component of
all kinds of projects it may pay off.

Furthermore I would favor to seperate the distribution of functor right
away into two jars as in Logging. 
 - one which contains only the basic interfaces functor/*.java
 - one for all the implementations functor/*/*.java (functor-implementation)
Maybe then other commons project would be less hesitent to include a
dependency on functor-interface.  While very advanced functor
bell & whistles stuff could still be added to functor-implementation
without jar-bloating other projects which do not care for functors.


Arnd Kohrs  -  Castify Networks

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message