You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Rodney Waldhoff <rw...@apache.org> on 2003/07/14 20:07:26 UTC
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
RE: [functor] generators
Posted by Rodney Waldhoff <rw...@apache.org>.
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
RE: [functor] generators
Posted by Jason Horman <ja...@jhorman.org>.
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