commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arron Bates <>
Subject Re: [collections] - Few more collections for the masses... (Lazy collections)
Date Wed, 22 May 2002 02:18:40 GMT
  ...and sometimes I just walk the path of least resistance :)
I've taken all the relevant options and made the changes.

- now managed from the single factory class, all the wrappers are inner 
classes. Just as java.util.Collections and 
- the internal object creation (the wrapper logic itself) works off a 
factory mechanism defined by an interface (I called it 
"SimpleObjectFactory"). Has an internal StandardFactory for the simple 
use of class definitions to create objects. Naturally, other logic can 
provide custom version.
- there's only three wrappers off three collections. Only those which 
call on specific objects are relevant. The others are generalised calls 
on the entire collection, and not useable for this purpose.
- the result of calling subList(int a, int b) on the wrapped 
implementation is in turn wrapped again, so it mimics the ability of the 

If you want to look at code...


Stephen Colebourne wrote:

>>>The decision to code PredicateUtils as one class is because:
>>>1) This is how java collections do it ( Collections.unmodifiableList() /
>>>Collections.synchronizedList() )
>>>2) Having 8 new classes in the public commons collections API was deemed
>>>undesirable. (In fact there are 18 static nested classes in
>>>The decision to use factory methods is because:
>>>1) This is how java collections do it ( Collections.unmodifiableList() /
>>>Collections.synchronizedList() )
>>>2) It allows the implementation classes to be completely hidden leading
>to a
>>>compact API.
>>The single entry point of the factory is fine, but I just don't like the
>>composition of that source file. Including java.util.Collections. It's
>>horrible. I'd rather have the other classes there but confined to the
>>package. Done widely in other api's. Same thing without the nasty
>For OSS work I could be tempted to agree with you (a time implementation I'm
>looking after uses the package scoped classes approach). But collections
>(java/apache) seem to like one class. C'est la vie.

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message