(comments inline) On Thu, 13 Mar 2003, Arnd Kohrs wrote:
> > 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 > valuable. Thanks for your encouragement. > I guess you are already aware of the article > http://c2.com/cgi/wiki?BlocksInJava (may be it was even you who posted > it on the commons-dev list). Yes. > 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. > The letters "uate" are a rather small part of what makes defining blocks as anonymous inner classes in java syntactically awkward, but there may be something to your argument there. While I have an opinion, any isomorphic representation of these interfaces is pretty much OK with me. > - IMHO "Predicate.test()" is (in a world of JUnit testers) a bit > misleading, since "test" has overloaded semantics. I like "is()". I'm also a little troubled by Predicate.test, but more so by Predicate.is. My thinking was that in most cases, the method-name for the functor is a verb that can be applied to the functor. I.e., you "run" a Procedure or "evaluate" a Function, but you don't "is" a Predicate. (And similiarly, you could look at those verbs as applying to the arguments of those functors.) My preference would have been for Predicate.assert, but that's out for obvious reasons, or Predicate.evaluate, but I think we want to keep the Function and Predicate signatures different. Recently it occurred to me (following the language Backus uses in "Can Programming Be Liberated from the von Neumann Style?" <http://www.stanford.edu/class/cs242/readings/backus.pdf>, and is sometimes used in mathematical circles) that it might be reasonable to say you "apply" a Function (i.e., Function.apply), which would free up evaluate for the Predicate method. (Predicate.is does give an almost sentence-like reading of expressions, but the subject and object are flipped in a vaguely yoda-esque way: strongInTheForce.is(youngSkywalker).) > - 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. We don't have much to say about toString other than "it's always nice to define a toString method", but the functor interfaces do specify an additional contract on equals and hashCode. Having the methods in the interface definition gives us a place to document that contract (e.g. <http://tinyurl.com/7es2>) and helps to remind folks that like to cut-and-paste interface declarations to begin an interface definition about these contracts. > 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. No, I fully agree. Now is the time to hash this sort of thing out, and to make it as right as we can. > 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 > (funtor-interface) > - one for all the implementations functor/*/*.java (functor-implementation) That had been my original thinking as well. I suspect that the the most likely type of dependency for components that are extensible via Functor will be something in between those two JARs, including the functor/*.java interfaces, but also the functor/core/*.java implementations. If I have a method that accepts UnaryFunction, I think I'm likely to want to assume IdentityFunction for null, for example. I agree that at least those two JARs should be available, or perhaps simply "interface" and (the not-disjoint) "full". > 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. > > Cheers, > > Arnd. > -- > Arnd Kohrs - Castify Networks > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
