[functor] draft proposal

[Rodney Waldhoff <rw...@apache.org>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [functor] draft proposal

[Rodney Waldhoff <rw...@apache.org>]

On Mon, 16 Dec 2002, Ola Berg wrote:

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

Perhaps, but that's also covered by (indeed encouraged by) "miminal",
don't you think? I think "this package cannot depedend on anything else"
is a kind of a silly thing to put in the charter.  It doesn't help define
the scope in any meaningful way, and IMO may just contribute to the
"monolithic component" design approach--functor needs feature "y" but
can't depend upon another component, so I guess feature "y" must be added
to functor.

The expression "minimal" should encourage but not strictly require zero
dependencies, since no one can argue that 0 is not minimal.  If functor
adds a dependency, then there should be a good reason for it, else we fail
to meet this "minimal dependency" criterion.

>
> >
> > 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?)
>

Doh, good catch. Yes, the final draft should remove or replace one of
those "Factory"s

 - R.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [functor] draft proposal

[Ola Berg <ol...@ports.se>]

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:   <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: [functor] draft proposal

[Stephen Colebourne <sc...@btopenworld.com>]

Henri wrote:
> I can't fault much of your proposal document. It's well put together and
> if functor were to be a separate package, would serve well.
+1

> I am worried that there is a time/cost to pay for lots of small components
> which have to be release managed, bug managed, documented and checked out
> for irregularities. Having a component on its own is a good way to get it
> going, but merging components for better dependency handling and
> management has pluses once they get going. Especially if they share
> developers, scope-domain and users.
Our experience with releases shows commons is a release late, release
infrequently place. I find it difficult to see how more components, with the
same number of people, will help.


One possible solution could be for this proposal to be used within [lang] to
define the functor package there. Similar 'definition's could be written for
other [lang] packages.

Stephen





--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [functor] draft proposal

[Henri Yandell <ba...@generationjava.com>]

On Fri, 13 Dec 2002, Rodney Waldhoff wrote:

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

I have some agreement with the worry over a one-man project. This can be
solved however by some focusing on proposing new contributor's for
committer status. There are developers out there trying to contribute to
projects like Collections, the functors and Codec, and those projects need
the maintainance and visionnaires.

> =============================================

> [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

Good set of links. I'd not seen a proper description of Functor before
now.

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

This is a problem, but not necessarily a Lang/Functor one. We have many
intertwined projects, and it's increasing. We're going to hit a circiular
dependency that cannot be avoided at some point soon. Or we're going to
spend lots of effort trying to avoid one.

When that happens, I hope that we'll be able to merge projects and not
have worries over backwards compatibility that actually stop development.

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

'non-normative'? Can you use a more easily understood word?

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

I can't fault much of your proposal document. It's well put together and
if functor were to be a separate package, would serve well.

I would be hoping to include the functor code in areas that I watch over
in Commons so would happily be one volunteer.

I am worried that there is a time/cost to pay for lots of small components
which have to be release managed, bug managed, documented and checked out
for irregularities. Having a component on its own is a good way to get it
going, but merging components for better dependency handling and
management has pluses once they get going. Especially if they share
developers, scope-domain and users.

This might be an argument for another thread though.

Hen


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>