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/06 16:25:01 UTC
Re: [collections] Desirability of typed and other
validatedCollections
If you read the paragraph that starts with...
> I wasn't proposing to get rid of the casting involved when retrieving
Objects
You'll see that what I'm suggesting has nothing to do with casting.
Also, downloading a prototype implementation of the java compiler, which
requires the 1.4 compiler to work, is exactly the type of arrangement
that a lot of developers are not able to set up. I don't have access to
these things in my current production environment: I cannot install
them, I cannot run them.
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
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
Re: [collections] Desirability of typed and
othervalidatedCollections
Posted by grumpoxl <mh...@stargate.net>.
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 and othervalidatedCollections
Posted by Stephen Colebourne <sc...@btopenworld.com>.
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
Re: [collections] Desirability of typed and other
validatedCollections
Posted by grumpoxl <mh...@stargate.net>.
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 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
Re: [collections] [PATCH] typed Collection, List, Set, Bag, and Map
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Patches applied, thanks.
Stephen
----- Original Message -----
From: "grumpoxl" <mh...@stargate.net>
To: <co...@jakarta.apache.org>
Sent: Tuesday, March 11, 2003 1:58 AM
Subject: Re: [collections] [PATCH] typed Collection, List, Set, Bag, and Map
> I added typedXXX(Collection, Class) and typedXXX(Class) methods in each
> of the Utils classes.
>
> I added some test cases for typedXXX, which were pretty close copies of
> the tests for predicatedXXX. I didn't see any tests for BagUtils.
>
> I may have accidentally hit the "format" command in Eclipse while
> editing MapUtils and TestCollectionUtils, that is why the patch files
> are so large. If necessary, I can redo those changes on a fresh
> version.
>
> A desire for predicatedXXX(Predicate) methods in the Utils classes was
> mentioned before. If all of these changes can be committed... I can
> submit patches for those soon after.
>
> Thanks, let me know if there are any problems.
>
>
>
----------------------------------------------------------------------------
----
> ---------------------------------------------------------------------
> 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 other validatedCollections
Posted by Stephen Colebourne <sc...@btopenworld.com>.
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 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
Re: [collections] Desirability of typed and other validated
Collections
Posted by grumpoxl <mh...@stargate.net>.
My idea was to provide 3 constructors;
TypedCollection() - no type specified, uses default class (Object) and
default Collection type (ArrayList)
TypedCollection(Collection) - no type, but uses specified collection
TypedCollection(Class) - uses specified type and default Collection
TypedCollection(Class, Collection) - uses specified type and Collection
The ability to specify the Collection implementation would allow
complete flexibility. The only logic in TypedCollection is validation
of items inside the Collection, everything else is delegated to the
underlying Collection. It could be combined with predicates to do a
number of things.
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.
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.
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
Re: [collections] Desirability of typed and othervalidatedCollections
Posted by Henri Yandell <ba...@generationjava.com>.
On Thu, 6 Mar 2003, 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.
It's quite disheartening isn't it :(
Hen
---------------------------------------------------------------------
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 Stephen Colebourne <sc...@btopenworld.com>.
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