Comments inline > ============================================= > [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.
...or 'none'? or 'absolutely minimal'? I think that a separate Functor package will fail should it be dependent on others. > > 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 Closure, Factory, Predicate, Factory... two kind of factories ? ;-) (I guess you mean Transformer?) > 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]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
