You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Rodney Waldhoff <rw...@apache.org> on 2002/12/19 22:51:27 UTC
[VOTE][PROPOSAL] commons-functor
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE][PROPOSAL] commons-functor
Posted by Rodney Waldhoff <rw...@apache.org>.
On Thu, 19 Dec 2002, Costin Manolache wrote:
> 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 ).
This is meant as a resolution to round of "where should this class be
located" discussions, and seems or at least seemed to represent an
informal consesnsus on the issue (cf
<http://archives.apache.org/eyebrowse/SearchList?listName=commons-dev@jakarta.apache.org&searchText=functor+-cvs&defaultField=body>).
> 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.
Those aren't my reasons.
For me, the primary reasons for this proposal are:
(1) a functor-related component forms a cohesive, atomic unit that meets
both the hard and soft criteria for a commons component--it has a clearly
defined purpose and scope, it does one thing, and hopefully will do it
well. The functor types are likely to be used, changed and released
together, and to be mutually dependent. (The same statements are not true
for either functor-in-lang or functor-in-collections.)
(2) there is some demand for a functor-related component, as witnessed by
the similar code in collections and lang (and it's easy to find instances
of functor-related interfaces throughout commons and for that matter
jakarta), and the sometimes lively debate on this issue.
> Or just pick a neutral interface and have both implement the interface.
Well yes, that's one approach. Arguably, that's this approach. But absent
functor, where does that interface live?
> Or even better - pick a design pattern ( a method name and signature )
I suspect there is a reason no one has developed the "design patterns
framework", or for that matter, why design patterns are generally
expressed as prose rather than code.
> and use reflection to wrap any class that implement the pattern.
A reflection-based implementation (for instance, something like
MethodPredicate(Object,Method)) seems appropriate in some circumstances
(indeed I've had something like that in mind for a little while), but
again, absent functor, where should that functionality live?
For an extended analysis of this situtation, see my next post.
- R.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE][PROPOSAL] commons-functor
Posted by Costin Manolache <cm...@yahoo.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE][PROPOSAL] commons-functor
Posted by Scott Sanders <sa...@apache.org>.
On Fri, Dec 27, 2002 at 01:27:01PM -0500, Henri Yandell wrote:
>
> Vote +1 to the vote for that and it could be ;)
>
> ..
>
> sorry. hard to resist :)
+1 for functors in lang. I think this is part of the 'missing link' that got left out of java.lang.
--
Scott Sanders - sanders@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE][PROPOSAL] commons-functor
Posted by Morgan Delagrange <md...@yahoo.com>.
Hey Scott,
I think the point of the functors proposal was that
functors seemed significant enough to warrant their
own component. Also functors are pretty wide of
lang's "java.lang and java.lang-like functionality"
scope. However it looks like the functor vote didn't
succeed, so functors will probably end up in lang by
default, unless it is vetoed.
- Morgan
--- Henri Yandell <ba...@generationjava.com> wrote:
>
> Vote +1 to the vote for that and it could be ;)
>
> ..
>
> sorry. hard to resist :)
>
> On Thu, 26 Dec 2002, Scott Sanders wrote:
>
> > Why couldn't this just be in the next version of
> lang?
> > --
> > Scott Sanders - sanders@apache.org
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE][PROPOSAL] commons-functor
Posted by Henri Yandell <ba...@generationjava.com>.
Vote +1 to the vote for that and it could be ;)
..
sorry. hard to resist :)
On Thu, 26 Dec 2002, Scott Sanders wrote:
> Why couldn't this just be in the next version of lang?
> --
> Scott Sanders - sanders@apache.org
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE][PROPOSAL] commons-functor
Posted by Scott Sanders <sa...@apache.org>.
Why couldn't this just be in the next version of lang?
--
Scott Sanders - sanders@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE][PROPOSAL] commons-functor
Posted by Stephen Colebourne <sc...@btopenworld.com>.
> [ ] +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
> [X] -1 - I vote against this proposal for the following
> technical reason: ______________
After much thought I vote -1.
Creating a functor component just results in further problems down the line
with dependencies. Both [io] and the identifier code, currently in [util]
use functors. A separate component requires
- [collections] to add a dependency to [functor], and yet that still doesn't
give it access to other [lang] functionality that it might use, eg. Enum to
create a dedicated fast EnumMap
- [io] to add another dependency ([lang] and [functor], not just [lang])
- the identifier code to find another home again (it was to go in [lang],
but it can't if this change occurs because [lang] won't depend on [functor].
And as Costin pointed out, we're all very bored with dependency debates.
Adding more components worsens the issue, not improves it.
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE][PROPOSAL] commons-functor
Posted by Martin Cooper <ma...@apache.org>.
+0, but section 2.2 of the proposal needs to be fixed. There are no
conventions of the "general Jakarta-Commons project", since each component
may select its own. If the intent is to use the Commons default (Sun coding
conventions), then the proposal should say as much. Otherwise, it needs to
define the desired conventions in some other concrete way.
--
Martin Cooper
On Thu, 19 Dec 2002, 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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE][PROPOSAL] commons-functor
Posted by Rodney Waldhoff <rw...@apache.org>.
I'm in favor, of course.
----- Ballot: Cut Here -----
I vote as follows on approving Functor as a
Jakarta-Commons component:
[X] +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 -----
On Thu, 19 Dec 2002, 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.
<snip/>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE][PROPOSAL] commons-functor
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 19 Dec 2002, Rodney Waldhoff wrote:
>
> ----- 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
> [X] +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 -----
>
Out of curiousity, do you consider APIs and implementations of the "chain
of responsibility" pattern [GOF95] to be in scope for [functor]?
Essentially, you'd be composing chains out of functors in some fashion,
and then passing in an execution request to the first element of the
chain, which could then delegate as needed. The Filter APIs in Servlet
2.3 are one possible implementation of this pattern, although you could
certainly do the actual APIs in a variety of ways.
I've been noodling on some ideas that could benefit from a common API for
this pattern.
Craig McClanahan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE][PROPOSAL] commons-functor
Posted by Morgan Delagrange <md...@yahoo.com>.
> I vote as follows on approving Functor as a
> Jakarta-Commons component:
>
> [X] +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: ______________
=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>