RFC: Proposing a high level iteration facility based on Collections

Question

I am requesting for comments for an experimental package I developed providing a high level facility for iteration on Java 2 Collections.
You can browse the javadoc at http://www.cacs.louisiana.edu/~cxg9789/javautils/ and the code is available for download from http://www.cacs.louisiana.edu/~cxg9789.
Basically, the package provides an interface Task that has a single method job() which is called for every element in a given collection. There are some static methods for using this kind of scheme and iterating over collections. An example would be: Iteration.loop(collection, new Task() {
          public void job(Object o) {
            // do something on o here
        });Now you may wonder what is the use of going into this much trouble when I can just get an iterator and do the same thing? Well, creating a class that represents the whole iteration opens a number of new possibilities. You can now have methods and variables exclusive for the specific iteration and reuse it. You can even subclass it for variants. This proved very useful in my application especially when I developed the StringTask class that is available in the same package.
Nevertheless, you can see it for yourself that we've got rid of the iterator and the condition checking that appears in conventional loop constructs. For details you can look at the Iteration at http://www.cacs.louisiana.edu/~cxg9789/javautils/edu/ull/cgunay/utils/Iteration.html and StringTask at http://www.cacs.louisiana.edu/~cxg9789/javautils/edu/ull/cgunay/utils/StringTask.html
I was wondering if you Java developers would find such a scheme useful. Thanks for your interest..

Answer 1

Heh... now I need to remember back...
No I don't, the internet comes to the rescue :-) I
was wrong, apply is the simple "function apply"
function, the list function of interest was (is)
called map.
http://www.cse.unsw.edu.au/~paull/cs1011/hof.html
This was very helpful. Now I know what you're saying. Actually this may very well be the hidden influence that lead to this system. The map operation also exists in Lisp and Scheme. I remember really liking it when I first learned about it.
My approach isn't exactly the same as neither of map, fold or filter. But I think I can create subclasses of Task which act the same way with these. I will try to do this in the near future.
Just as a comment on the design, I would have
maneuvered the list of getSomeResult() into an object
that knows how to render itself as a String. That may
well be using your Iteration feature over the internal
list, or other feature as the developer sees fit.This point is well taken. Actually my program uses this kind of approach in many places, however I wanted to give a less confusing example here.
Your iteration is a perfectly valid pattern to iterate
over a collection, and one that could be
applied in many places in my code. I'm unsure I
will migrate to use it, because it tends
towards a large number of small objects to perform its
function... which sometimes can be a simplification,
but in this case can obscure multi-threading issues...
spreading a loop over a collection across multiple
classes makes it less obvious what is happening to the
contents, or what synchronization is required, what
locks have been acquired, or what concurrent
modifications are possible.On the other hand, it might be more secure to have operations on collections in a place as an Iteration class to keep them together. Maybe you already mentioned it in your message. I can understand your concern in using the system, though.
To keep this information in one place, you could use
an anonymous inner class, but then you have lost the
reusability and succinctness of the iteration, which
are two of its largest benefits (Being a high-level
function using centralised, tested code being the
third, and probably the largest)I started using small inner classes very extensively. Maybe this can alleviate the problem, since they're not anonymous and can be reused. However, there is still a problem using (subclassing) them from outside of the class. I found a way to do this, too. It only works in special situations, though.
Assume you have an inner class:
public class Outer {
  class Inner { ... }
}You can extend this inner class if you have another class extending the Outer:
class NewOuter extends Outer {
  class Inner extends Outer.Inner { ... }
Thinking about it, your iteration is at a higher level
than foreach... and would benefit from using it
if were ever supported by the JVM. They are slightly
orthogonal approaches to looping abstraction, foreach
being syntactic and your pattern being heuristic.We're in tune here, I'd be interested to use the foreach operator and the Iterable interface as primitives in my system if they will ever be provided in Java. Currently, they are not offering me anything extra, since the Collection interface provides me with what I need.