commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack, Paul" <>
Subject RE: [collection] Collections for primitives
Date Tue, 25 Jun 2002 17:54:34 GMT
> Maybe I'm still missing something, but I don't see how you could be 
> passing in two different typed objects into containsKey -- 
> one correct (Integer) and one incorrect without having a "bug" 
> elsewhere in the application (e.g. ignoring the conversion failure).  

...yeah, I realized right after I posted it that my example wasn't
a good one.  Let me revise. :)

Actually, I'm not sure I can provide you with exactly what you 
asked for.  Offhand I can't think of a case where the wrong type
is sent to a collection and it isn't exceptional.

However, a Predicated collection could be used to enforce things
OTHER THAN type conversion, right?

Let's say the Integers have to be positive, and less than 1,000,000
to be valid user ids.

We're then using a Predicated map to check three things:

1.  The objects are Integers;
2.  They're positive;
3.  They're less than 1,000,000.

Whereas yes, we could check for those in the conversion routine,
it'd be easier to just use Integer.parseInt(String) and let the
already existing Predicate check that the integer's valid.

Or, maybe userIds are Strings, but must obey certain rules.  In
this case there isn't any parsing really; or, if there is, then
that parsing is already contained in the Predicate for the map,
so there's no need to rewrite it as an external conversion routine.

Hm.  Based on what I've just said, it might be defensible for the
Predicate and primitive collections to remain as they are.  For
the primitive case, it's always exceptional to pass in a non-primitive;
but for the predicate case, it may or may not be exceptional to pass
in a value that fails the predicate.  Hence the different behaviors.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message