commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodney Waldhoff <rwaldh...@apache.org>
Subject RE: [functor] generators
Date Tue, 15 Jul 2003 20:01:47 GMT
On Tue, 15 Jul 2003, Jason Horman wrote:

> I am +1 to your proposal of removing specific generators (EachLine) from
> functor. I assume you will keep EachElement and NumberRange.

Yes, I just want to avoid "obscure" dependencies for the time being, where
I'll define obscure as most things outside of java.lang java.util, or
maybe more to the point, anything that requires Exception.

There's already a lot of code/classes in functor just supporting the
"basic" functionality.  I'd like to try to keep the 1.0 release relatively
simple (and therefore avoid any contriversial issues).

> The reason I included EachLine was really to demonstrate how a Generator can be
> more powerful than an Iterator. That reason being that the EachLine Generator
> controls the opening, iteration, and closing of the file such that it is
> transparent to the functors applied.

And a good example it is.

> Do you plan on keeping CollectionAlgorithms around given that Algorithms
> duplicates much of its functionality? The two methods that are missing from
> Algorithms are remove and retain. The reason for this was that the concept of
> removal is a little funny when the generator is an EachLine file generator.

No, that's one of several things I think it would be useful to sort out.

> I do think it would be useful to have a place for utility Generators. I already
> have an EachLine, XPath, and database generator that can be quite useful.

I'm not sure where to put these for now.  Personally I think in the long
run something like EachLine belongs in commons-io (or something like it),
database generator (EachRow?) belongs in commons-sql (or something like
it), etc.  Functor is remarkably general purpose.  I think we're better
off keeping domain-specific functors with other domain-specific code.  In
the short run we could sit on them, build out a functor-sandbox source
tree, move them to another component, or potentially create new sandbox
components like commons-functor-io, commons-functor-sql, etc.  Not knowing
which path is best, I'm inclined to just sit on them for now.  No
individual functor is particuarly complicated to implement.

- Rod <http://radio.weblogs.com/0122027/>
>
> -jason
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message