commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject Re: [functor] draft proposal
Date Sat, 14 Dec 2002 06:24:49 GMT


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


Mime
View raw message