commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@eurobell.co.uk>
Subject Re: [Collections][SUBMIT] TypedList
Date Thu, 25 Apr 2002 19:30:05 GMT
This is sounding dangerously like a consensus...

On implementation, I don't think that it will be practical to have all the
implementations as inner classes in CollectionsUtils. So I'm favour creating
package scoped classes.

I may be able to get away with just four basic classes though:
AbstractPredicateMap
AbstractTransormMap
AbstractPredicateCollection
AbstractTransformCollection
Within each of these files I can then place inner subclasses for each of the
variations on a theme collections. I think that avoids too many classes in
the collections package.

I would declare the inner classes as final, as they would not be on the
public API even for subclassing.

Stephen

From: James Strachan <james_strachan@yahoo.co.uk>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Sent: Thursday, April 25, 2002 6:01 PM
Subject: Re: [Collections][SUBMIT] TypedList


> +1 for the static factory method approach like the Collections static
> methods. These methods could go nicely in the existing CollecitonUtils
> class.
>
> We already have a ProxyMap which is useful for this kind of thing; maybe
we
> could add ProxyList and ProxySet and use those in the implementations of
the
> factory methods?
>
> James
> ----- Original Message -----
> From: "Jack, Paul" <pjack@sfaf.org>
> To: "'Jakarta Commons Developers List'" <commons-dev@jakarta.apache.org>
> Sent: Thursday, April 25, 2002 5:44 PM
> Subject: RE: [Collections][SUBMIT] TypedList
>
>
> > > I agree.  I think one of the benefits of the Proxy pattern is that one
> > > proxy can be wrapped inside another.  So PredicatedList and
> > > TransformingList would be separate classes, since they represent two
> > > different responsibilities.  If you want to do both, put one inside
the
> > > other.
> >
> > I agree here too.  Having them in separate classes would also allow me
> > to control what order things happen in:
> >
> > new PredicateList(new TransformList(transform, list), predicate)
> > new TransformList(new PredicateList(predicate, list), transform)
> >
> > The above could do different things.  If I predicate first, I can strip
> > out illegal values to my transform; or, I might be using a transform
> > that can produce null values that I don't want stored in my list, so
> > I'd predicate afterwards; or both; I think this is a much more flexible
> > pattern.
> >
> > Having said all that, I think we should keep in mind that if we want to
> > be complete, we're talking about adding fourteen new classes:
> >
> > PredicateBag
> > PredicateCollection
> > PredicateList
> > PredicateMap
> > PredicateSet
> > PredicateSortedMap
> > PredicateSortedSet
> > TransformBag
> > TransformCollection
> > TransformList
> > TransformMap
> > TransformSet
> > TransformSortedMap
> > TransformSortedSet
> >
> > Seems like a lot to include in the public API.  Instead I'd advocate
doing
> > what java.util.Collections does; have one class (maybe WrapperUtils? Or
> > maybe
> > within CollectionUtils?) that provides static methods for returning
> wrapped
> > collections:
> >
> >   public static List predicateList(List list, Predicate predicate);
> >   // other fourteen similar methods...
> >
> > We could then hide the fourteen implementation classes either by making
> them
> > inner classes of WrapperUtils or by giving them package scope.
> >
> > Having the classes themselves exposed in the public API seems wasteful,
as
> > they're difficult to subclass (unless we also expose the sublist,
submap,
> > collection view and iterator classes -- dozens more) and are meant for
> > composition.
> >
> > -Paul
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> <mailto:commons-dev-help@jakarta.apache.org>
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
> --
> To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>
>
>


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


Mime
View raw message