commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juozas Baliuka" <bali...@centras.lt>
Subject Re: [Collections][SUBMIT] TypedList - FilterList
Date Wed, 24 Apr 2002 21:03:43 GMT
Hi,
I am not sure it is good idea to use transformer this way. I expect this on
list :
<code>
 list.add( obj );
 assertTrue( "expected the same instance", list.get( list.size() - 1)) ==
obj );
</code>




----- Original Message -----
From: "Stephen Colebourne" <scolebourne@eurobell.co.uk>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Wednesday, April 24, 2002 10:23 PM
Subject: Re: [Collections][SUBMIT] TypedList - FilterList


> Please find attached the code for FilterList. This permits both
> transformation and validation:
> /**
>  * FilterList is a list wrapper that supports validation and
transformation
>  * of <em>input</em> into the list.
>  * All objects to be added to the list are first transformed, and then
>  * validated. Either of these steps may throw an
> <tt>IllegalArgumentException</tt>.
>  * <p>
>  * The transform step could be used to type convert objects on list entry,
>  * for example to convert String objects to Integer objects. The
validation
>  * step could be used to ensure that the list does not contain nulls, or
>  * that only instanceof of a particular class are allowed. The mechanism
>  * for both is a plugin interface - <tt>Predicate</tt> for validation,
>  * <tt>Transformer</tt> for transformation.
>  * <p>
>  * The common case of validating for an instanceof a particular class
>  * (or subclass) is available by using the <tt>getTypeCheckedList</tt>
>  * static factory method.
>  * <p>
>  * By default, this class will use an ArrayList behind the scenes.
>  * Alternatively, a List implementation, such as <tt>LinkedList</tt>, may
>  * be wrapped by the constructor.
>  *
>  * @author Stephen Colebourne
>  */
>
> Feedback welcome. If this is agreed as an acceptable final design, and
there
> is demand, I will code up Map and Set variations.
>
> Stephen
>
> From: James Strachan <james_strachan@yahoo.co.uk>
> > I agree Stephen. I like the simple approach of just having a Predicate -
> > nice and simple. Also I don't quite see how/why we'd want different
> > Predicate & Transformer operations based on which methods we're calling
on
> > the collections (adding/removing/getting etc). This more complex
approach
> > probably requires different collection implementations.
> >
> > Though having an optional Transformer applied to objects being
> added/removed
> > might be useful too. e.g. this approach would make it easy to allow type
> > coercion into Strings or Numbers if required or to use interning to
> promote
> > object sharing . I guess in this case the transformer should fire first
> and
> > the predicate second?
> >
> > Also I like Henri's idea of using the 'Filter' name/concept as in
Servlet
> > Filters. Then we could have FilterList that can have a Predicate and/or
a
> > Transformer for doing simple transforms to objects as they get
> added/removed
> > to the list as well as filtering out bad objects.
>
> I'm concentrating on the add operations.
>
> > After reading (part of) Joshua Block's Effective Java (which I'll finish
> > eventually, its a great book!), in the scenario of adding an invalid
> object
> > we should probably throw an exception, reusing one from the JDK.
> > java.lang.IllegalArgumentException is probably the one to use. Thoughts?
>
> It does throw an IllegalArgumentException.
>
> >
> > James
> > ----- Original Message -----
> > From: "Stephen Colebourne" <scolebourne@eurobell.co.uk>
> > To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> > Sent: Tuesday, April 23, 2002 10:46 PM
> > Subject: Re: [Collections][SUBMIT] TypedList
> >
> >
> > > OK, this is a different design to one using Predicate, although
> obviously
> > a
> > > similar purpose. Before I can continue and finish the other
collections,
> I
> > > would like a decision on which way to go ;-)
> > >
> > > This design gives much more power, but is therefore more complex (more
> > > methods, more choice). Maybe there is a case for both. Maybe there is
a
> > case
> > > for wrapping a Predicate in a CollectionFilter. Not quite sure yet.
> > >
> > > I would suggest the following interface is necessary to fully express
> the
> > > possibilities:
> > > public interface CollectionFilter {
> > >   // predicate
> > >     public boolean allowUpdate(Object obj, Collection coll);
> > >  // transform
> > >     public Object beforeUpdate(Object obj, Collection coll);
> > >  // info
> > >     public void afterUpdate(Object obj, Collection coll);
> > >
> > >   // predicate
> > >     public boolean allowGet(Object obj, Collection coll);
> > >  // info ???
> > >     public void beforeGet(Object obj, Collection coll);
> > >  // transform
> > >     public Object afterGet(Object obj, Collection coll);
> > >
> > >   // predicate
> > >     public boolean allowRemove(Object obj, Collection coll);
> > >  // ???
> > >     public Object beforeRemove(Object obj, Collection coll);
> > >  // ???
> > >     public Object afterRemove(Object obj, Collection coll);
> > >  }
> > >
> > > Hmm. Having sketched that out, I think I'm tending towards keeping it
> > simple
> > > and sticking with PredicateList and TransformList. Views? I need
> guidance
> > on
> > > this one before I can continue.
> > >
> > > Stephen
> > >
> > > From: Henri Yandell <bayard@generationjava.com>
> > > > public interface CollectionFilter {
> > > >
> > > >     public Object beforeAdd(Object obj, Collection coll);
> > > >
> > > >     public Object beforeRemove(Object obj, Collection coll);
> > > >     public Object afterRemove(Object obj, Collection coll);
> > > >
> > > > }
> > > >
> > > >
> > > > And same (ish) for Map? And then List/Set extend Collection filter
and
> > add
> > > > events?
> > > >
> > > > When something is added to the collection, it checks with beforeAdd,
> > > > passing the object and the collection. In TypedFilter it is set to
> only
> > > > allow Strings. It finds out the object isn't a String and returns
> null?
> > > >
> > > > But does that mean return or insert null. Can we have an interface
> that
> > > > means both Predicate and Transform?? Or should they be separate.
> > > >
> > > > Hen
> > > >
> > > > > So we need something more than the existing Predicate/Transformer
> > > classes
> > > > > then? I think I need to go and code something to it working...
> > > > > Stephen
> > > >
> > > >
> > > > --
> > > > 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>
> >
> >
> > _________________________________________________________
> > 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>


--
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