Actually, I see that you did implement iterators as well (nice). I
would have expected you to leverage them in the CollectionUtils
methods. Perhaps you wanted to avoid the extra iterator instantiation?

FYI, I found a couple of small (but important ;) bugs in a casual
comparison to my implementation:

FilterIterator.next() seems to assume hasNext() is always called
before it.

FilterIterator().remove() could delete the wrong item if its called
after a hasNext().

dave


On Thu, 03 May 2001 19:20:31 -0700, David Rees wrote:

>For the Closure stuff I have implemented a set of similar functions
>that I use a fair amount (I have a Smalltalk background and couldn't
>stand living without them). However, after working with them for a
>while I rewrote them with a design difference that I think results in
>a more useful set of classes.
>
>Essentially I placed all the collection functionality in Iterators.
>This allows them to be nested and also passed around without having to
>create interim collections. I think this is really nice because its
>easy to create new Iterator combinations (collect, select, collect).
>
>I still have the basic Util methods, but they simply use the correct
>iterator (rather than a normal iterator) when building the result
>collection.
>
>I, of course, have different names for the Closure classes and some of
>the Util methods. If people like, I can try and package them up using
>these Closure classes and these Util APIs. In that way, the tests
>written for them will work for these as well.
>
>As a final thought, to be closer to Smalltalk (if you care) "find"
>becomes "detect" and "forAllDo" is just "do".
>
>dave
>
>
>On Sun, 29 Apr 2001 12:37:45 +0100, James Strachan wrote:
>
>>I've a variety of collection utility classes that I've used on a various
>>projects that I'd like to contribute to the collections project.
>>
>>I've attached all the source code for the new classes in the
>>org.apache.commons.collections package with ASF licences attached as a JAR.
>>Its all ready to just unjar into the source directory of the collections
>>project. I haven't included JUnit test scripts for this code yet, I thought
>>I'd wait for approval of the patch first before porting those.
>>
>>The code consists of new classes together with a patch to CollectionUtils to
>>add a number of extra helper methods. I've attached a seperate patchfile.txt
>>which contains the new methods on CollectionUtils.
>>
>>Probably the easiest way to browse the code is to unjar the patch.jar into
>>the source directory and build the javadoc and browse that. I'll try give a
>>brief overview of the classes here.
>>
>>
>>Adapters
>>======
>>ArrayIterator: like ArrayEnumeration for the Iterator interface
>>
>>EnumerationIterator & IteratorEnumeration:  allow both Iterator and
>>Enumeration objects to be adapted to each other. Trivial stuff but I've
>>found this useful.
>>
>>Map implementations
>>==============
>>BeanMap: properties of the bean appear as values. so map.get( "name" ) =
>>bean.getName();
>>
>>LRUMap: implements an LRU caching mechanism, useful for fixed size caches
>>
>>SoftRefHashMap: implements a HashMap using SoftReferences such that the JVM
>>can garbage collect values if memory gets low. Again useful for caches.
>>
>>Various
>>=====
>>MapUtils: provides a number of typesafe getter methods to extract specific
>>types from Maps. Again trivial but helpful. There's also some printing
>>methods to dump nested Map objects to streams for debugging purposes.
>>
>>SynchronizedQueue: I've used this class alot in multi-threaded environments
>>for implementing blocking producer / consumer queues.
>>
>>Closures
>>======
>>After reading a bit about Closures in languages such as Smalltalk and some
>>JavaWorld article a year or so ago, I implemented a simple "closures"
>>implementation using Java 2 collections.
>>
>>Firstly there are 3 simple interfaces:-
>>
>>public interface Predicate {
>>
>>    /** @return true if the input object matches this predicate, else
>>returns false
>>      */
>>    public boolean evaluate(Object input);
>>}
>>
>>public interface Closure {
>>
>>    /** Performs some operation on the input object
>>      */
>>    public void execute(Object input);
>>}
>>
>>public interface Transformer {
>>
>>    /** Transforms the input object (leaving it unchanged) into some output
>>object.
>>      * @return the transformation of the input object to the output object
>>      */
>>    public Object transform(Object input);
>>}
>>
>>All of the above I've found quite useful in their own right doing other
>>code.
>>
>>CollectionUtils has a variety of closure style methods (as well as other
>>useful Collection based methods) most of which use one or more of the above
>>interfaces.
>>I'll list a few example methods here:-
>>
>>    Collection collection = ...;
>>
>>    Predicate predicate = new Predicate() {
>>        public boolean evaluate(Object object) {
>>            if ( object instanceof String ) {
>>                String s = (String) object;
>>                return s.startsWith( "foo" );
>>            }
>>            return false;
>>        }
>>    };
>>
>>    Closure closure = new Closure() {
>>        public void execute(Object object) {
>>            // do something
>>        }
>>    };
>>
>>    Transformer transformer = new Transformer () {
>>        public Object transform(Object object) {
>>            return "something: " + object;
>>        }
>>    };
>>
>>    // find first element matching predicate
>>    Object value = CollectionUtils.find( collection, predicate );
>>
>>    // find all elements matching predicate
>>    Collection subset = CollectionUtils.select( collection, predicate );
>>
>>    // perform a closure on the objects in some collection
>>    CollectionUtils.forAllDo( collection, closure );
>>
>>    // return a collection of transformed objects
>>    Collection newColl = CollectionUtils.collect( collection, transformer );
>>
>>
>>Plus a few additional iterators which use these interfaces such as
>>
>>    FilterIterator which takes an Iterator and a Predicate to perform
>>filtered iteration
>>    TransformIterator which takes an Iterator and a Transformer to provide a
>>transformed iteration set
>>
>>
>>If some or all of these classes get accepted, I'd be happy to check them
>>into CVS and create JUnit test cases for them all.
>>
>>Thoughts?
>>
>>James
>

Reply via email to