commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [collection] Collections for primitives
Date Tue, 25 Jun 2002 16:06:28 GMT
If the Predicate collections currently in PredicateUtils are not fail-fast I
consider that to be a bug. I don't understand what you mean about false
results though.

Stephen

----- Original Message -----
From: "Jack, Paul" <pjack@sfaf.org>
To: "'Jakarta Commons Developers List'" <commons-dev@jakarta.apache.org>
Sent: Tuesday, June 25, 2002 4:24 PM
Subject: RE: [collection] Collections for primitives


> I can see merit in both permissive and fail-fast
> implementations, though I tend to favor the permissive
> approach.
>
> However, it bothers me that current the Predicate
> collections use the permissive approach but the
> primitive collections use the fail-fast approach.
>
> For consistency's sake, I'd like to see consensus and
> rewrite one or the other.
>
> Middle ground might be acheived by having Predicate
> use fail-fast collections, but providing another set
> of decorators that automatically translates raised
> exceptions into false results...or something...
>
> -Paul
>
>
> > -----Original Message-----
> > From: Ola Berg [mailto:ola.berg@arkitema.se]
> > Sent: Saturday, June 22, 2002 4:23 PM
> > To: commons-dev@jakarta.apache.org
> > Subject: Re: [collection] Collections for primitives
> >
> >
> > michael wrote:
> > >In my opinion, if you\'re asking an int based collection for the
> > >presence of a String, it\'s an error in your program and warrants the
> > >throwing of an exception (ClassCastException) at runtime.
> >
> > The problem is that it is runtime type checking. If you adhere to the
> > principle that the exception should be unchecked if the exception
> > could be avoided by the programmer (like NullPointerException), a
> > ClassCastException is cruel, as you have no idea (given a List) that
> > the collection is type-safe and that the type safety is asserted via
> > ClassCastExceptions even in the lookup methods.
> >
> > This is actually an argument against the parts of the Collection
> > contract in the first place. Given any List, you have no way of
> > telling if it is going to throw ClassCastExceptions or not, except by
> > trying. Just as you don\'t know if it supports any of the optional
> > methods (adding etc). Which means that you in reality has to check and
> > deal with all four unchecked exceptions (IllegalArgument,
> > UnsupportedOperation, ClassCast, NullPointer) when using any of the
> > basic collection methods on any List you don\'t know the implementing
> > class for.
> >
> > But since we cannot change the contract, we can at least do the best
> > of it. Asking an int based collection for a String is most certainly
> > wrong. But asking _any_ collection (typed or not, you just
> > don\'t know)
> > for a String can\'t be wrong. Or asking any collection for the
> > existence of any object regardless of type. Type safe collections are
> > special, I agree to that. But I see no reason to make them more
> > special than needed.
> >
> > With the path chosen, the number of runtime checks becomes a burden
> > for the user of the API. I might not know what List implementation I
> > have in my hand, and the idea with common interfaces is that I
> > or my API:s really shouldn\'t need to know.
> >
> > Throwing ClassCastException when adding might be needed for type
> > safety. But for lookups it really isn\'t necessary.
> > Especially when you
> > have collections with elements of different types in it.
> >
> > Permissive and fail-safe approaches has their places, just as the
> > strict and asserting has. If the type-safe classes in
> > Commons Collection all takes the (unnecessary) strict approach, I
> > would say that there is a need for more permissive ones. And in order
> > to reduce duplication of effort, I suggest that the strict approach is
> > implemented through decoration of the permissive ones, as the other
> > way around is impossible.
> >
> > >If you
> > >think an addition to the documentation is warranted even though the
> > >contract states it might be thrown when an ineligible element is
> > >passed, then please post a patch to that effect.
> >
> > Just because the contract states that it _might_ be thrown, the
> > behaviour _should_ be documented, regardless of what path the
> > Collections component choses to take. Just as a well
> > documented read-only collection states that the modifying operations
> > are unsupported and will result in an exception.
> >
> > I will gladly supply the patch, but I am also interested in other\'s
> > opinion on this.
> >
> > /O
> >
> > --------------------
> > ola.berg@arkitema.se
> > 0733 - 99 99 17
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:commons-dev-help@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message