commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodney Waldhoff <>
Subject [functor] draft proposal
Date Fri, 13 Dec 2002 20:11:02 GMT
In part of the discussion of his recent proposal, Stephen Coleburn wrote:

> I am trying to move forward _now_. Creating
> [functor] would involve a sandbox project,
> moving the code again (effectively
> recreating [pattern]), a strong possibility
> of a one-man project, thus no possibility
> of promotion to commons-proper, thus we just
> go round in circles again.

I don't think that needs to be the case.  We can move forward on a
commons-functor proposal now, and this don't require "sandboxed" time.  In
fact, here's a draft proposal seeking comment.

[DRAFT] Proposal for a 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 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

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

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,
Factory, Predicate, and Factory interfaces and some of the 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


(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 Jakarta-Commons list for

(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.

(There are clearly many interested parties here. I'm loathe to list them
for fear of missing someone central.  Count me in. Feel free to volunteer
yourself in response to this draft.)

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

View raw message