commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Horman" <ja...@jhorman.org>
Subject RE: [functor] generators
Date Tue, 15 Jul 2003 19:07:35 GMT
I am +1 to your proposal of removing specific generators (EachLine) from
functor. I assume you will keep EachElement and NumberRange.

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.

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.

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.

-jason

-----Original Message-----
From: Rodney Waldhoff [mailto:rwaldhoff@apache.org]
Sent: Monday, July 14, 2003 2:07 PM
To: Jakarta Commons Developers List
Subject: Re: [functor] generators


I've been digging into the generator stuff Jason submitted a while back a
little more closely, and I have a few questions and comments I'd like to
drill into, but let me start with an easy one.

Currently functor.generators includes a io subpackage, containing
EachLine, which is a Generator for each line of some BufferedReader.
Since BufferedReader may throw an IOException, this introduces a need for
GeneratorException (a RuntimeException wrapping an Exception, in this
case, an IOException), which in turn introduces a dependency on JDK 1.4
(for the RuntimeException(Exception) constructor).

In the long run, it seems like there may be quite a number of functor
subpackage like io (or net, or sql, etc.).  These may have a home in
functor itself, in "extension" jars distributed via the functor component
(functor-core.jar, functor-io.jar, functor-sql.jar, etc.) or in some other
component (in commons or elsewhere) that happens to use or support the
functor interfaces (commons-io.jar, for example).

In the short run, which may include everything up to a 1.0 release, I
wonder if we may be better off not including these sorts of extensions in
functor itself.  These aren't difficult to create outside of functor and
not having them will allow us to punt on a host of issues (packaging and
exception handling to name just two) in the interim.

In particular, this would mean dropping EachLine (and hence
GeneratorException) from current HEAD, which would remove a few types, a
package, and as restore support of JDK 1.2 and 1.3 (as well as 1.1 with
the java.util collections).

Complaints?

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


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




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