commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From grumpoxl <mhawtho...@stargate.net>
Subject Re: [collections] Desirability of typed and other validatedCollections
Date Fri, 07 Mar 2003 20:01:28 GMT
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" <mhawthorne@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
Integers 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


Mime
View raw message