commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
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 
result. 

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.

Costin


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] - 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,
> 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:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message