commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: [VOTE][PROPOSAL] commons-functor
Date Thu, 19 Dec 2002 23:23:00 GMT
If this means another round of "where should this class be located"
and dependency nightmares: I'm -1 ( it is a majority vote and probably that
won't change the result, but I want to express my frustration somehow ).

It seems one of the reasons for this proposal is that both collections
and lang have something like that and can't agree on a dependency. 
A better solution would be to have a majority vote ( or flip 
a coin ) to decide which of the 2 should have functor, and live with the 

Or just pick a neutral interface and have both implement the interface.
Or even better - pick a design pattern ( a method name and signature )
and use reflection to wrap any class that implement the pattern.

Or propose a JSR.


Rodney Waldhoff wrote:

> Following the Jakarta-Commons guidelines and as previously discussed on
> this list, here is a proposal for a new commons component: functor.
> As always, all Jakarta-Commons committers are eligible to vote.  Other
> interested parties are welcome to state their opinion as well, but only
> committer's votes are binding.
> ----- Ballot: Cut Here -----
> I vote as follows on approving Functor as a
> Jakarta-Commons component:
> [ ] +1 - I support this proposal and am willing to help
> [ ] +0 - I support this proposal, but cannot assist
> [ ] -0 - I don't support this proposal
> [ ] -1 - I vote against this proposal for the following
>          technical reason: ______________
> ----- Ballot: Cut Here -----
> Proposal for the Commons-Functor Component
> (0) rationale
> A "functor" is an entity which serves the role of a function but can be
> operated upon like an object [Wiki].  It is a common object oriented
> design idiom.  For example, this concept surfaces in Smalltalk and Ruby as
> blocks and in C++ as function pointers.  In Java functors are typically
> implemented as interfaces defined by a single, generic member function.
> Functors support a number of interesting and powerful design strategies,
> including the command, visitor and factory-related design patterns
> [GOF95], functional programming [FP], higher order functions (functions
> that take functions as parameters) and various generic and modular
> programming techniques.
> Several functor implementations and variations exist within Java projects
> at Apache and within Jakarta-Commons in particular.  A shared
> implementation of the functor-related interfaces, common functors and
> functor utilities will support greater re-use and interoperability between
> these implementations and extensions.
> [Wiki] -
> [GOF95] - "Design Patterns" by Gamma, Helm, Johnson, and Vlissides. ISBN
> [0-201-63361-2 FP] -
> (1) scope of the package
> The component shall create and maintain common functor and functor-related
> interfaces, implementations and utilities written in the Java language to
> be distributed under the ASF license, for use and extension by other
> Jakarta-Commons, Jakarta, and Apache components, as well as for the
> greater Java community.
> (1.5) interaction with other packages
> Functor's dependencies upon other components and external libraries should
> be minimal.
> Other components and projects that apply the functor idiom are encouraged
> but not required to use and extend the Functor implementation.
> (2) identify the initial source from which the subproject is to be
> populated
> The Functor component will be initially populated with source derived,
> copied, or moved from existing functor-related code available in
> Jakarta-Commons.  Some non-normative examples include the Closure,
> Predicate, and Factory interfaces and related utilities in
> commons-collections, the org.apache.commons.lang.functor package of
> commons-lang, as well as recent relevant submissions that have not yet
> found a place in Jakarta-Commons.
> (2.1) identify the base name for the package
> org.apache.commons.functor
> (2.2) identify the coding conventions for this package
> The code follows the conventions of the general Jakarta-Commons project.
> (3) identify any Jakarta-Commons resources to be created
> (3.1) mailing list
> Until traffic justifies, the package will use the commons-dev and
> commons-user lists for communication.  The community is encouraged to add
> "[functor]" prefix to all commons-functor related mails to either list.
> (3.2) CVS repositories
> For the time being, the package will use a root branch of the
> Jakarta-Commons CVS, for example, "jakarta-commons/functor".
> (3.3) Bugzilla
> The package should be listed as a component of under the Jakarta-Commons
> Bugzilla entry.
> (4) identify the initial set of committers to be listed in the Status
> File.
>  Stephen Colebourne
>  James Strachan
>  Rodney Waldhoff

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

View raw message