You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by grumpoxl <mh...@stargate.net> on 2003/03/08 20:49:09 UTC
Re: [collections] Desirability of typed and
othervalidatedCollections
I see validate(Collection) and validate(Predicate[]) in PredicateUtils,
but I don't quite understand how those will get me what I want. Can you
explain further?
On Sat, 2003-03-08 at 12:25, Stephen Colebourne wrote:
> I agree with your logic. However this is what predicatedCollection does, see
> validate().
>
> Stephen
>
> ----- Original Message -----
> From: "grumpoxl" <mh...@stargate.net>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Friday, March 07, 2003 8:01 PM
> Subject: Re: [collections] Desirability of typed and
> othervalidatedCollections
>
>
> > Using your suggestion, if I do
> >
> > Collection c = CollectionUtils.typedCollection(Integer.class)
> > c.add("whoops");
> >
> > it seems that, due to the instanceOf Predicate, "whoops" will not be
> > added. However, the behavior that I desired is for the Collection to
> > throw some type of RuntimeException indicating that a String cannot be
> > added to an Integer Collection.
> >
> > Secretly discarding all non-matching entries can be useful in some
> > situations, but seems slightly confusing in this one.
> >
> > I would prefer a more aggressive Predicate. What do you think?
> >
> >
> > On Thu, 2003-03-06 at 23:24, Stephen Colebourne wrote:
> > > From: "grumpoxl" <mh...@stargate.net>
> > > > I don't see the PredicateUtils class, I'm assuming by saying "with a
> > > > little tweaking in CVS" you mean it has to be created.
> > > No, PredicateUtils exists in [lang]. The tweaking means that it
> implements
> > > the same interface, but in a different package. Simple enough to tweak.
> > > (Hopefully we can just convince other committers to depend on the [lang]
> > > version.....)
> > >
> > >
> > > > I agree that the Predicate route is more flexible. However, I think
> > > > that in time, I would end up writing a small convenience method or
> class
> > > > just to wrap your suggested solution.
> > > >
> > > > So, the big question is ...
> > > >
> > > > What do you prefer:
> > > >
> > > > 1) List list = ListUtils.predicatedList(new ArrayList(),
> > > > PredicateUtils.instanceofPredicate(String.class);
> > > >
> > > > Map map = MapUtils.predicatedMap(new HashMap(),
> > > > PredicateUtils.instanceOfPredicate(String.class),
> > > > PredicateUtils.instanceOfPredicate(Integer.class))
> > > >
> > > > or
> > > >
> > > > 2) Collection c = new TypedCollection(String.class, new ArrayList());
> > > >
> > > > Map map = new TypedMap(String.class, Integer.class, new HashMap())
> > > >
> > > >
> > > > I am not suggesting that just because my preference (#2) is less
> wordy,
> > > > that it is better. It's a convenient, specific implementation of
> > > > Predicates.
> > > >
> > > > I am willing to write either one (or both). Thanks for your opinion.
> > >
> > > I think that my preference would be to add new methods to
> CollectionUtils,
> > > ListUtils, SetUtils, MapUtils and BagUtils:
> > >
> > > CollectionUtils.typedCollection(Collection coll, Class type) {
> > > return CollectionUtils.predicatedCollection(coll,
> > > PredicateUtils.instanceofPredicate(type));
> > > }
> > > etc.
> > >
> > >
> > > Also, currently you have to pass a collection in to be wrapped. I would
> > > support a patch for additional methods that had a default collection
> > > selected, thus:
> > >
> > > ListUtils.predicatedList(List, Predicate) // exists
> > > ListUtils.predicatedList(Predicate) // new, creates new ArrayList
> > >
> > > Stephen
> > >
> > >
> > >
> > > > On Thu, 2003-03-06 at 22:20, Stephen Colebourne wrote:
> > > > > I believe that my first submission to commons was a proposed typed
> > > > > collection. Now here I am maintaining the package and we've come
> full
> > > > > circle....
> > > > >
> > > > > My original proposal was changed to become the Predicated Collection
> > > > > decorators. Unfortunately, these got stymied by politics over which
> > > project
> > > > > got to implement the predicates.
> > > > >
> > > > > Anyway, you can (with just a little teaking from the CVS), write:
> > > > > List list = ListUtils.predicatedList(new ArrayList(),
> > > > > PredicateUtils.instanceofPredicate(String.class);
> > > > >
> > > > > So, the question is whether there is enough justification for a
> > > > > 'convenience' implementation of TypedList et al.
> > > > > List list = new TypedList(String.class);
> > > > >
> > > > > The problem is where do you stop? Should it allow nulls? etc. the
> > > Predicate
> > > > > route is more flexible. Overall, I think I'm +0.
> > > > >
> > > > > Stephen
> > > > >
> > > > > > So once again, the question is: in a world where Java 1.3 may be
> the
> > > > > > only show in town for at least another 6 months or so (and
> possibly
> > > > > > longer than that), would typed Collections be a useful tool?
> > > > > >
> > > > > > The amount of work required to implement these classes is trivial.
> I
> > > > > > wrote a TypedCollection class in about a 1/2 hour (and I code
> pretty
> > > > > > slowly).
> > > > > >
> > > > > > Is is not wasted effort if type validation is something you would
> > > like,
> > > > > > and you do not have access to 1.5, 1.4, or any prototype compilers
> or
> > > > > > JVMs.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, 2003-03-06 at 20:07, David Graham wrote:
> > > > > > > You don't need 1.5 to use generics because you can download the
> > > > > prototype
> > > > > > > implementation already. This further alleviates any need to
> > > duplicate
> > > > > this
> > > > > > > effort in Jakarta. IMO, all this redundant work just to avoid
> > > casting
> > > > > isn't
> > > > > > > worth it.
> > > > > > >
> > > > > > > David
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > > >
> > > > > > > > > It seems like a waste of time to write/maintain code that
> will
> > > be
> > > > > > > >obsolete
> > > > > > > > > quite soon. I don't find casting collection objects to be
> > > terribly
> > > > > > > >painful
> > > > > > > > > and 1.5 will provide the function you would be coding.
> > > > > > > > >
> > > > > > > > > David
> > > > > > > >
> > > > > > > >It is true that Java 1.5 will include generics, and that any
> typed
> > > > > > > >Collections that I create will eventually be replaced.
> However, it
> > > > > > > >seems to me that Java 1.5 will not be available anytime soon,
> so
> > > any
> > > > > > > >classes written to solve this problem will not be obsolete for
> a
> > > good
> > > > > > > >while.
> > > > > > > >
> > > > > > > >Even after the release of 1.5, not all developers will have
> access
> > > to
> > > > > > > >it. The HP-UX production machines at my current job are still
> > > running
> > > > > > > >1.3, due to a kernel upgrade that 1.4 requires. I'm sure that
> a
> > > lot of
> > > > > > > >developers are in similar situations.
> > > > > > > >
> > > > > > > >It seems that the general Jakarta philosophy still leans toward
> > > > > > > >supporting Java 1.3 at a minimum. So, the question isn't so
> much
> > > about
> > > > > > > >the possibility of these classes being replaced by better
> > > > > > > >versions from Sun, but whether or not typed Collections would
> be a
> > > > > > > >useful addition to the collections package. I am going to
> write
> > > the
> > > > > > > >classes either way, I was just wondering if anyone else was
> > > interested.
> > > > > > > >
> > > > > > > >I wasn't proposing to get rid of the casting involved when
> > > retrieving
> > > > > > > >Objects from Collections, there is no way to do that while
> > > implementing
> > > > > > > >Collection or Map. I was proposing overrides to add(Object),
> > > > > > > >addAll(Collection), and the Constructors, to add validation to
> the
> > > > > input
> > > > > > > >Objects or Collections. Anyone sending or receiving a
> Collection
> > > could
> > > > > > > >instantly validate whether the content is what they expect,
> rather
> > > than
> > > > > > > >casting and getting a ClassCastException along the way. I
> would
> > > > > imagine
> > > > > > > >that illegal classes would still throw some type of
> > > RuntimeException,
> > > > > > > >perhaps a custom Exception which is more descriptive than
> > > ClassCast.
> > > > > > > >
> > > > > > > >Anyone else agree/disagree?
> > > > > > > >
> > > > > > > >
> > > > > > > > > >Is there any interest in creating typed Collections? Even
> > > though
> > > > > it
> > > > > > > > > >looks like Java is providing generics with 1.5, this could
> > > serve as
> > > > > a
> > > > > > > > > >good holdover until then,
> > > > > > > > > >
> > > > > > > > > >- a TypedCollection(Integer.class) would only allow Integer
> s to
> > > its
> > > > > add
> > > > > > > > > >methods
> > > > > > > > > >
> > > > > > > > > >- a TypedMap(String.class, Integer.class) would only allow
> > > String
> > > > > keys
> > > > > > > > > >and Integer values
> > > > > > > > > >
> > > > > > > > > >I understand that this type of thing could already by done
> > > using
> > > > > > > > > >Predicates and
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > >---------------------------------------------------------------------
> > > > > > > >To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> > > > > > > >For additional commands, e-mail:
> > > commons-dev-help@jakarta.apache.org
> > > > > > >
> > > > > > >
> > > > > > >
> _________________________________________________________________
> > > > > > > MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.
> > > > > > > http://join.msn.com/?page=features/virus
> > > > > > >
> > > > > > >
> > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> > > > > > > For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> > > > > >
> > > > >
> > > > >
> > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >
> > >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Desirability of typed andothervalidatedCollections
Posted by Stephen Colebourne <sc...@btopenworld.com>.
> I'm going to work on some patches for a typed Collection, List, Set, and
> Map. I have a few questions that I didn't see answered on the Jakarta
> site:
>
> 1) What version of Java should I use?
Collections is JDK1.2 or later
> 2) Since I will be modifying multiple files, should I do a diff for each
> modified file and attach multiple files, or can I do a diff against the
> entire source tree and attach one larger file? I think I've seen it
> done both ways, is there a preference?
One diff for each related change is my preference. This may involve multiple
files.
> 3) The collections package does not seem to have a dependency on lang,
> so should I refrain from using PredicateUtils? If so, I'll have to
> write a small private method to create an instanceOf Predicate, which is
> not a big deal.
Yes, for the moment [collections] must remain independent of [lang]. The
instanceof predicate should be private though so it could be replaced later
if [lang] is added as a dependency.
Stephen
> Thanks.
>
>
>
>
> On Sat, 2003-03-08 at 19:49, grumpoxl wrote:
> > I see validate(Collection) and validate(Predicate[]) in PredicateUtils,
> > but I don't quite understand how those will get me what I want. Can you
> > explain further?
> >
> >
> > On Sat, 2003-03-08 at 12:25, Stephen Colebourne wrote:
> > > I agree with your logic. However this is what predicatedCollection
does, see
> > > validate().
> > >
> > > Stephen
> > >
> > > ----- Original Message -----
> > > From: "grumpoxl" <mh...@stargate.net>
> > > To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> > > Sent: Friday, March 07, 2003 8:01 PM
> > > Subject: Re: [collections] Desirability of typed and
> > > othervalidatedCollections
> > >
> > >
> > > > Using your suggestion, if I do
> > > >
> > > > Collection c = CollectionUtils.typedCollection(Integer.class)
> > > > c.add("whoops");
> > > >
> > > > it seems that, due to the instanceOf Predicate, "whoops" will not be
> > > > added. However, the behavior that I desired is for the Collection
to
> > > > throw some type of RuntimeException indicating that a String cannot
be
> > > > added to an Integer Collection.
> > > >
> > > > Secretly discarding all non-matching entries can be useful in some
> > > > situations, but seems slightly confusing in this one.
> > > >
> > > > I would prefer a more aggressive Predicate. What do you think?
> > > >
> > > >
> > > > On Thu, 2003-03-06 at 23:24, Stephen Colebourne wrote:
> > > > > From: "grumpoxl" <mh...@stargate.net>
> > > > > > I don't see the PredicateUtils class, I'm assuming by saying
"with a
> > > > > > little tweaking in CVS" you mean it has to be created.
> > > > > No, PredicateUtils exists in [lang]. The tweaking means that it
> > > implements
> > > > > the same interface, but in a different package. Simple enough to
tweak.
> > > > > (Hopefully we can just convince other committers to depend on the
[lang]
> > > > > version.....)
> > > > >
> > > > >
> > > > > > I agree that the Predicate route is more flexible. However, I
think
> > > > > > that in time, I would end up writing a small convenience method
or
> > > class
> > > > > > just to wrap your suggested solution.
> > > > > >
> > > > > > So, the big question is ...
> > > > > >
> > > > > > What do you prefer:
> > > > > >
> > > > > > 1) List list = ListUtils.predicatedList(new ArrayList(),
> > > > > > PredicateUtils.instanceofPredicate(String.class);
> > > > > >
> > > > > > Map map = MapUtils.predicatedMap(new HashMap(),
> > > > > > PredicateUtils.instanceOfPredicate(String.class),
> > > > > > PredicateUtils.instanceOfPredicate(Integer.class))
> > > > > >
> > > > > > or
> > > > > >
> > > > > > 2) Collection c = new TypedCollection(String.class, new
ArrayList());
> > > > > >
> > > > > > Map map = new TypedMap(String.class, Integer.class, new
HashMap())
> > > > > >
> > > > > >
> > > > > > I am not suggesting that just because my preference (#2) is less
> > > wordy,
> > > > > > that it is better. It's a convenient, specific implementation
of
> > > > > > Predicates.
> > > > > >
> > > > > > I am willing to write either one (or both). Thanks for your
opinion.
> > > > >
> > > > > I think that my preference would be to add new methods to
> > > CollectionUtils,
> > > > > ListUtils, SetUtils, MapUtils and BagUtils:
> > > > >
> > > > > CollectionUtils.typedCollection(Collection coll, Class type) {
> > > > > return CollectionUtils.predicatedCollection(coll,
> > > > > PredicateUtils.instanceofPredicate(type));
> > > > > }
> > > > > etc.
> > > > >
> > > > >
> > > > > Also, currently you have to pass a collection in to be wrapped. I
would
> > > > > support a patch for additional methods that had a default
collection
> > > > > selected, thus:
> > > > >
> > > > > ListUtils.predicatedList(List, Predicate) // exists
> > > > > ListUtils.predicatedList(Predicate) // new, creates new ArrayList
> > > > >
> > > > > Stephen
> > > > >
> > > > >
> > > > >
> > > > > > On Thu, 2003-03-06 at 22:20, Stephen Colebourne wrote:
> > > > > > > I believe that my first submission to commons was a proposed
typed
> > > > > > > collection. Now here I am maintaining the package and we've
come
> > > full
> > > > > > > circle....
> > > > > > >
> > > > > > > My original proposal was changed to become the Predicated
Collection
> > > > > > > decorators. Unfortunately, these got stymied by politics over
which
> > > > > project
> > > > > > > got to implement the predicates.
> > > > > > >
> > > > > > > Anyway, you can (with just a little teaking from the CVS),
write:
> > > > > > > List list = ListUtils.predicatedList(new ArrayList(),
> > > > > > > PredicateUtils.instanceofPredicate(String.class);
> > > > > > >
> > > > > > > So, the question is whether there is enough justification for
a
> > > > > > > 'convenience' implementation of TypedList et al.
> > > > > > > List list = new TypedList(String.class);
> > > > > > >
> > > > > > > The problem is where do you stop? Should it allow nulls? etc.
the
> > > > > Predicate
> > > > > > > route is more flexible. Overall, I think I'm +0.
> > > > > > >
> > > > > > > Stephen
> > > > > > >
> > > > > > > > So once again, the question is: in a world where Java 1.3
may be
> > > the
> > > > > > > > only show in town for at least another 6 months or so (and
> > > possibly
> > > > > > > > longer than that), would typed Collections be a useful tool?
> > > > > > > >
> > > > > > > > The amount of work required to implement these classes is
trivial.
> > > I
> > > > > > > > wrote a TypedCollection class in about a 1/2 hour (and I
code
> > > pretty
> > > > > > > > slowly).
> > > > > > > >
> > > > > > > > Is is not wasted effort if type validation is something you
would
> > > > > like,
> > > > > > > > and you do not have access to 1.5, 1.4, or any prototype
compilers
> > > or
> > > > > > > > JVMs.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Thu, 2003-03-06 at 20:07, David Graham wrote:
> > > > > > > > > You don't need 1.5 to use generics because you can
download the
> > > > > > > prototype
> > > > > > > > > implementation already. This further alleviates any need
to
> > > > > duplicate
> > > > > > > this
> > > > > > > > > effort in Jakarta. IMO, all this redundant work just to
avoid
> > > > > casting
> > > > > > > isn't
> > > > > > > > > worth it.
> > > > > > > > >
> > > > > > > > > David
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > It seems like a waste of time to write/maintain code
that
> > > will
> > > > > be
> > > > > > > > > >obsolete
> > > > > > > > > > > quite soon. I don't find casting collection objects
to be
> > > > > terribly
> > > > > > > > > >painful
> > > > > > > > > > > and 1.5 will provide the function you would be coding.
> > > > > > > > > > >
> > > > > > > > > > > David
> > > > > > > > > >
> > > > > > > > > >It is true that Java 1.5 will include generics, and that
any
> > > typed
> > > > > > > > > >Collections that I create will eventually be replaced.
> > > However, it
> > > > > > > > > >seems to me that Java 1.5 will not be available anytime
soon,
> > > so
> > > > > any
> > > > > > > > > >classes written to solve this problem will not be
obsolete for
> > > a
> > > > > good
> > > > > > > > > >while.
> > > > > > > > > >
> > > > > > > > > >Even after the release of 1.5, not all developers will
have
> > > access
> > > > > to
> > > > > > > > > >it. The HP-UX production machines at my current job are
still
> > > > > running
> > > > > > > > > >1.3, due to a kernel upgrade that 1.4 requires. I'm sure
that
> > > a
> > > > > lot of
> > > > > > > > > >developers are in similar situations.
> > > > > > > > > >
> > > > > > > > > >It seems that the general Jakarta philosophy still leans
toward
> > > > > > > > > >supporting Java 1.3 at a minimum. So, the question isn't
so
> > > much
> > > > > about
> > > > > > > > > >the possibility of these classes being replaced by better
> > > > > > > > > >versions from Sun, but whether or not typed Collections
would
> > > be a
> > > > > > > > > >useful addition to the collections package. I am going
to
> > > write
> > > > > the
> > > > > > > > > >classes either way, I was just wondering if anyone else
was
> > > > > interested.
> > > > > > > > > >
> > > > > > > > > >I wasn't proposing to get rid of the casting involved
when
> > > > > retrieving
> > > > > > > > > >Objects from Collections, there is no way to do that
while
> > > > > implementing
> > > > > > > > > >Collection or Map. I was proposing overrides to
add(Object),
> > > > > > > > > >addAll(Collection), and the Constructors, to add
validation to
> > > the
> > > > > > > input
> > > > > > > > > >Objects or Collections. Anyone sending or receiving a
> > > Collection
> > > > > could
> > > > > > > > > >instantly validate whether the content is what they
expect,
> > > rather
> > > > > than
> > > > > > > > > >casting and getting a ClassCastException along the way.
I
> > > would
> > > > > > > imagine
> > > > > > > > > >that illegal classes would still throw some type of
> > > > > RuntimeException,
> > > > > > > > > >perhaps a custom Exception which is more descriptive than
> > > > > ClassCast.
> > > > > > > > > >
> > > > > > > > > >Anyone else agree/disagree?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > >Is there any interest in creating typed Collections?
Even
> > > > > though
> > > > > > > it
> > > > > > > > > > > >looks like Java is providing generics with 1.5, this
could
> > > > > serve as
> > > > > > > a
> > > > > > > > > > > >good holdover until then,
> > > > > > > > > > > >
> > > > > > > > > > > >- a TypedCollection(Integer.class) would only allow
Integer
> > > s to
> > > > > its
> > > > > > > add
> > > > > > > > > > > >methods
> > > > > > > > > > > >
> > > > > > > > > > > >- a TypedMap(String.class, Integer.class) would only
allow
> > > > > String
> > > > > > > keys
> > > > > > > > > > > >and Integer values
> > > > > > > > > > > >
> > > > > > > > > > > >I understand that this type of thing could already by
done
> > > > > using
> > > > > > > > > > > >Predicates and
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > >
>---------------------------------------------------------------------
> > > > > > > > > >To unsubscribe, e-mail:
> > > commons-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > >For additional commands, e-mail:
> > > > > commons-dev-help@jakarta.apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > _________________________________________________________________
> > > > > > > > > MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.
> > > > > > > > > http://join.msn.com/?page=features/virus
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail:
> > > commons-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > For additional commands, e-mail:
> > > commons-dev-help@jakarta.apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > >
> ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail:
commons-dev-unsubscribe@jakarta.apache.org
> > > > > > > > For additional commands, e-mail:
> > > commons-dev-help@jakarta.apache.org
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > >
> ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail:
commons-dev-unsubscribe@jakarta.apache.org
> > > > > > > For additional commands, e-mail:
commons-dev-help@jakarta.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail:
commons-dev-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail:
commons-dev-help@jakarta.apache.org
> > > > > >
> > > > >
> > > > >
> > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail:
commons-dev-help@jakarta.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >
> > >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Desirability of typed and
othervalidatedCollections
Posted by grumpoxl <mh...@stargate.net>.
Stephen,
Nevermind my last post, I looked at the source code, saw the
validate(Object) method in CollectionUtils.PredicatedCollection, I see
that it rejects Objects that don't pass.
I'm going to work on some patches for a typed Collection, List, Set, and
Map. I have a few questions that I didn't see answered on the Jakarta
site:
1) What version of Java should I use?
2) Since I will be modifying multiple files, should I do a diff for each
modified file and attach multiple files, or can I do a diff against the
entire source tree and attach one larger file? I think I've seen it
done both ways, is there a preference?
3) The collections package does not seem to have a dependency on lang,
so should I refrain from using PredicateUtils? If so, I'll have to
write a small private method to create an instanceOf Predicate, which is
not a big deal.
Thanks.
On Sat, 2003-03-08 at 19:49, grumpoxl wrote:
> I see validate(Collection) and validate(Predicate[]) in PredicateUtils,
> but I don't quite understand how those will get me what I want. Can you
> explain further?
>
>
> On Sat, 2003-03-08 at 12:25, Stephen Colebourne wrote:
> > I agree with your logic. However this is what predicatedCollection does, see
> > validate().
> >
> > Stephen
> >
> > ----- Original Message -----
> > From: "grumpoxl" <mh...@stargate.net>
> > To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> > Sent: Friday, March 07, 2003 8:01 PM
> > Subject: Re: [collections] Desirability of typed and
> > othervalidatedCollections
> >
> >
> > > Using your suggestion, if I do
> > >
> > > Collection c = CollectionUtils.typedCollection(Integer.class)
> > > c.add("whoops");
> > >
> > > it seems that, due to the instanceOf Predicate, "whoops" will not be
> > > added. However, the behavior that I desired is for the Collection to
> > > throw some type of RuntimeException indicating that a String cannot be
> > > added to an Integer Collection.
> > >
> > > Secretly discarding all non-matching entries can be useful in some
> > > situations, but seems slightly confusing in this one.
> > >
> > > I would prefer a more aggressive Predicate. What do you think?
> > >
> > >
> > > On Thu, 2003-03-06 at 23:24, Stephen Colebourne wrote:
> > > > From: "grumpoxl" <mh...@stargate.net>
> > > > > I don't see the PredicateUtils class, I'm assuming by saying "with a
> > > > > little tweaking in CVS" you mean it has to be created.
> > > > No, PredicateUtils exists in [lang]. The tweaking means that it
> > implements
> > > > the same interface, but in a different package. Simple enough to tweak.
> > > > (Hopefully we can just convince other committers to depend on the [lang]
> > > > version.....)
> > > >
> > > >
> > > > > I agree that the Predicate route is more flexible. However, I think
> > > > > that in time, I would end up writing a small convenience method or
> > class
> > > > > just to wrap your suggested solution.
> > > > >
> > > > > So, the big question is ...
> > > > >
> > > > > What do you prefer:
> > > > >
> > > > > 1) List list = ListUtils.predicatedList(new ArrayList(),
> > > > > PredicateUtils.instanceofPredicate(String.class);
> > > > >
> > > > > Map map = MapUtils.predicatedMap(new HashMap(),
> > > > > PredicateUtils.instanceOfPredicate(String.class),
> > > > > PredicateUtils.instanceOfPredicate(Integer.class))
> > > > >
> > > > > or
> > > > >
> > > > > 2) Collection c = new TypedCollection(String.class, new ArrayList());
> > > > >
> > > > > Map map = new TypedMap(String.class, Integer.class, new HashMap())
> > > > >
> > > > >
> > > > > I am not suggesting that just because my preference (#2) is less
> > wordy,
> > > > > that it is better. It's a convenient, specific implementation of
> > > > > Predicates.
> > > > >
> > > > > I am willing to write either one (or both). Thanks for your opinion.
> > > >
> > > > I think that my preference would be to add new methods to
> > CollectionUtils,
> > > > ListUtils, SetUtils, MapUtils and BagUtils:
> > > >
> > > > CollectionUtils.typedCollection(Collection coll, Class type) {
> > > > return CollectionUtils.predicatedCollection(coll,
> > > > PredicateUtils.instanceofPredicate(type));
> > > > }
> > > > etc.
> > > >
> > > >
> > > > Also, currently you have to pass a collection in to be wrapped. I would
> > > > support a patch for additional methods that had a default collection
> > > > selected, thus:
> > > >
> > > > ListUtils.predicatedList(List, Predicate) // exists
> > > > ListUtils.predicatedList(Predicate) // new, creates new ArrayList
> > > >
> > > > Stephen
> > > >
> > > >
> > > >
> > > > > On Thu, 2003-03-06 at 22:20, Stephen Colebourne wrote:
> > > > > > I believe that my first submission to commons was a proposed typed
> > > > > > collection. Now here I am maintaining the package and we've come
> > full
> > > > > > circle....
> > > > > >
> > > > > > My original proposal was changed to become the Predicated Collection
> > > > > > decorators. Unfortunately, these got stymied by politics over which
> > > > project
> > > > > > got to implement the predicates.
> > > > > >
> > > > > > Anyway, you can (with just a little teaking from the CVS), write:
> > > > > > List list = ListUtils.predicatedList(new ArrayList(),
> > > > > > PredicateUtils.instanceofPredicate(String.class);
> > > > > >
> > > > > > So, the question is whether there is enough justification for a
> > > > > > 'convenience' implementation of TypedList et al.
> > > > > > List list = new TypedList(String.class);
> > > > > >
> > > > > > The problem is where do you stop? Should it allow nulls? etc. the
> > > > Predicate
> > > > > > route is more flexible. Overall, I think I'm +0.
> > > > > >
> > > > > > Stephen
> > > > > >
> > > > > > > So once again, the question is: in a world where Java 1.3 may be
> > the
> > > > > > > only show in town for at least another 6 months or so (and
> > possibly
> > > > > > > longer than that), would typed Collections be a useful tool?
> > > > > > >
> > > > > > > The amount of work required to implement these classes is trivial.
> > I
> > > > > > > wrote a TypedCollection class in about a 1/2 hour (and I code
> > pretty
> > > > > > > slowly).
> > > > > > >
> > > > > > > Is is not wasted effort if type validation is something you would
> > > > like,
> > > > > > > and you do not have access to 1.5, 1.4, or any prototype compilers
> > or
> > > > > > > JVMs.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Thu, 2003-03-06 at 20:07, David Graham wrote:
> > > > > > > > You don't need 1.5 to use generics because you can download the
> > > > > > prototype
> > > > > > > > implementation already. This further alleviates any need to
> > > > duplicate
> > > > > > this
> > > > > > > > effort in Jakarta. IMO, all this redundant work just to avoid
> > > > casting
> > > > > > isn't
> > > > > > > > worth it.
> > > > > > > >
> > > > > > > > David
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > > >
> > > > > > > > > > It seems like a waste of time to write/maintain code that
> > will
> > > > be
> > > > > > > > >obsolete
> > > > > > > > > > quite soon. I don't find casting collection objects to be
> > > > terribly
> > > > > > > > >painful
> > > > > > > > > > and 1.5 will provide the function you would be coding.
> > > > > > > > > >
> > > > > > > > > > David
> > > > > > > > >
> > > > > > > > >It is true that Java 1.5 will include generics, and that any
> > typed
> > > > > > > > >Collections that I create will eventually be replaced.
> > However, it
> > > > > > > > >seems to me that Java 1.5 will not be available anytime soon,
> > so
> > > > any
> > > > > > > > >classes written to solve this problem will not be obsolete for
> > a
> > > > good
> > > > > > > > >while.
> > > > > > > > >
> > > > > > > > >Even after the release of 1.5, not all developers will have
> > access
> > > > to
> > > > > > > > >it. The HP-UX production machines at my current job are still
> > > > running
> > > > > > > > >1.3, due to a kernel upgrade that 1.4 requires. I'm sure that
> > a
> > > > lot of
> > > > > > > > >developers are in similar situations.
> > > > > > > > >
> > > > > > > > >It seems that the general Jakarta philosophy still leans toward
> > > > > > > > >supporting Java 1.3 at a minimum. So, the question isn't so
> > much
> > > > about
> > > > > > > > >the possibility of these classes being replaced by better
> > > > > > > > >versions from Sun, but whether or not typed Collections would
> > be a
> > > > > > > > >useful addition to the collections package. I am going to
> > write
> > > > the
> > > > > > > > >classes either way, I was just wondering if anyone else was
> > > > interested.
> > > > > > > > >
> > > > > > > > >I wasn't proposing to get rid of the casting involved when
> > > > retrieving
> > > > > > > > >Objects from Collections, there is no way to do that while
> > > > implementing
> > > > > > > > >Collection or Map. I was proposing overrides to add(Object),
> > > > > > > > >addAll(Collection), and the Constructors, to add validation to
> > the
> > > > > > input
> > > > > > > > >Objects or Collections. Anyone sending or receiving a
> > Collection
> > > > could
> > > > > > > > >instantly validate whether the content is what they expect,
> > rather
> > > > than
> > > > > > > > >casting and getting a ClassCastException along the way. I
> > would
> > > > > > imagine
> > > > > > > > >that illegal classes would still throw some type of
> > > > RuntimeException,
> > > > > > > > >perhaps a custom Exception which is more descriptive than
> > > > ClassCast.
> > > > > > > > >
> > > > > > > > >Anyone else agree/disagree?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > >Is there any interest in creating typed Collections? Even
> > > > though
> > > > > > it
> > > > > > > > > > >looks like Java is providing generics with 1.5, this could
> > > > serve as
> > > > > > a
> > > > > > > > > > >good holdover until then,
> > > > > > > > > > >
> > > > > > > > > > >- a TypedCollection(Integer.class) would only allow Integer
> > s to
> > > > its
> > > > > > add
> > > > > > > > > > >methods
> > > > > > > > > > >
> > > > > > > > > > >- a TypedMap(String.class, Integer.class) would only allow
> > > > String
> > > > > > keys
> > > > > > > > > > >and Integer values
> > > > > > > > > > >
> > > > > > > > > > >I understand that this type of thing could already by done
> > > > using
> > > > > > > > > > >Predicates and
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > >---------------------------------------------------------------------
> > > > > > > > >To unsubscribe, e-mail:
> > commons-dev-unsubscribe@jakarta.apache.org
> > > > > > > > >For additional commands, e-mail:
> > > > commons-dev-help@jakarta.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > _________________________________________________________________
> > > > > > > > MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.
> > > > > > > > http://join.msn.com/?page=features/virus
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail:
> > commons-dev-unsubscribe@jakarta.apache.org
> > > > > > > > For additional commands, e-mail:
> > commons-dev-help@jakarta.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > > > > > For additional commands, e-mail:
> > commons-dev-help@jakarta.apache.org
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > > >
> > > >
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org