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 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] - http://c2.com/cgi/wiki?FunctorObject [GOF95] - "Design Patterns" by Gamma, Helm, Johnson, and Vlissides. ISBN 0-201-63361-2 [FP] - http://www.cs.nott.ac.uk/~gmh/faq.html (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, 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 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 Jakarta-Commons list for communications. (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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
