You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@eurobell.co.uk> on 2002/04/24 22:23:26 UTC
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 <ja...@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" <sc...@eurobell.co.uk>
> To: "Jakarta Commons Developers List" <co...@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 <ba...@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:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
Re: [Collections][SUBMIT] TypedList - FilterList
Posted by Juozas Baliuka <ba...@centras.lt>.
Yes, it is very common. I sometimes use converters,
but some static method for List transformation Is more clear for me in this
case.
May be it is not a problem then
object.equals(transaformer.transform(object)) returns true,
but it looks like some side effect, if transformation is hidden for methods
like
lastIndexOf(object).
Wrapper hides some noise in code, but It is some magic : )
----- Original Message -----
From: "Stephen Colebourne" <sc...@eurobell.co.uk>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Thursday, April 25, 2002 9:31 PM
Subject: Re: [Collections][SUBMIT] TypedList - FilterList
> 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 <ba...@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" <sc...@eurobell.co.uk>
> > To: "Jakarta Commons Developers List" <co...@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 <ja...@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" <sc...@eurobell.co.uk>
> > > > To: "Jakarta Commons Developers List"
<co...@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 <ba...@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:
> > > > > <ma...@jakarta.apache.org>
> > > > > > For additional commands, e-mail:
> > > > > <ma...@jakarta.apache.org>
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > > For additional commands, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > >
> > > >
> > > > _________________________________________________________
> > > > Do You Yahoo!?
> > > > Get your free @yahoo.com address at http://mail.yahoo.com
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > > >
> > > >
> > >
> >
> >
>
> --------------------------------------------------------------------------
> --
> > ----
> >
> >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Collections][SUBMIT] TypedList - FilterList
Posted by Stephen Colebourne <sc...@eurobell.co.uk>.
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 <ba...@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" <sc...@eurobell.co.uk>
> To: "Jakarta Commons Developers List" <co...@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 <ja...@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" <sc...@eurobell.co.uk>
> > > To: "Jakarta Commons Developers List" <co...@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 <ba...@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:
> > > > <ma...@jakarta.apache.org>
> > > > > For additional commands, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > >
> > >
> > > _________________________________________________________
> > > Do You Yahoo!?
> > > Get your free @yahoo.com address at http://mail.yahoo.com
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
> > >
> >
>
>
> --------------------------------------------------------------------------
--
> ----
>
>
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Collections][SUBMIT] TypedList - FilterList
Posted by Juozas Baliuka <ba...@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" <sc...@eurobell.co.uk>
To: "Jakarta Commons Developers List" <co...@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 <ja...@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" <sc...@eurobell.co.uk>
> > To: "Jakarta Commons Developers List" <co...@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 <ba...@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:
> > > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > > >
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
> > _________________________________________________________
> > Do You Yahoo!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> >
>
----------------------------------------------------------------------------
----
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>