Interesting debate... Is the goal of the lang functor package to be re-used by other Commons project like Collections? If not, why not, is lang functor too "simple" even for that? Is there an agreement - with Collections for example - as to the adoption of lang functor?
Gary -----Original Message----- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Monday, March 24, 2003 4:43 PM To: Jakarta Commons Developers List Subject: Re: [lang] Functor debate From: "Arnd Kohrs" <[EMAIL PROTECTED]> > >>>>> "Stephen" == scolebourne <[EMAIL PROTECTED]> writes: (My short responses are due to time pressures...) > Arnd: > I don't agree that the current names chosen in lang.functor are simple, > and provided arguments for it in my first post (which you dit not > respond to). I do not make this up: When I read about a lang.functor > package to be included in 2.0, I checked it out, and was as confused > when I browsed over the class names, as people would be about the other > functors when first encountering. I needed to look-up for example > "Factory" and then mapped it in my mind to no-arg function. Factory by > itself does not sufficiently explain its nature. > > To put it differently, I suggest a "renaming" refactoring because the > current naming is not indicative enough nor coherent. > <snip> > I find it easier to adopt a conceptual framwork which has a coherent > naming convention. There is not coherence in "Executor", "Transformer", > "Factory" and "Predicate" although the coexitence of in the same package > would suggest so. The coherence is that they are basic callback interfaces. The name functor has been used, however this package should never attempt to be a full implementation of functor concepts or to include the work of [functor]. Its about standardising some very common callback interfaces, and providing implementations of those that can be shared. Are they named correctly? Well perhaps Factory could be called Creator, as this would be in line with the create() method. But otherwise I'm happy. > All which needs to be understood if these functors where renamed > following the naming which are customary in functor libraries and > which I referred to, is founded on two orthogonal concepts: > > 1. Functor Types > - Function: Functor which has a result > - Predicate: Functor which has a boolean result > - Procedure: Functor which has no result > > 2. Number of Arguments > - *Unary*Functor: one argument functor > - *Binary*Functor: two argument functor > - Functor: (Null-ary) no argument functor I don't dispute that this is the 'correct' or 'right' design for a full functor implementation. However this is very much bigger in concept, and in 'religion', than [lang] could support or would wish to. [lang]s functors do not have this goal - they aim to be simple commonly used callback interfaces. What I am arguing is that you may be reading too much into the word 'functor' in the [lang] context. What you are arguing for is [functor], which is fine if thats what you want to use. Stephen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
