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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
