Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <F4F2EBDF8C16D5118B6500508BD32B4DCB9A70@EARTH>
From: "Jack, Paul" <pjack@sfaf.org>
To: 'Jakarta Commons Developers List' <commons-dev@jakarta.apache.org>
Subject: RE: [collection] Collections for primitives
Date: Tue, 25 Jun 2002 08:24:31 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

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>