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 - FilterList
Date Thu, 25 Apr 2002 19:31:56 GMT
Normally, I would agree. This is standard collections behaviour. But the
whole purpose of the class is to change the added object (many possible
reasons, type conversion is the most common).

Stephen

From: Juozas Baliuka <baliuka@centras.lt>


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


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