commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack, Paul" <pj...@sfaf.org>
Subject RE: [collection] Collections for primitives
Date Tue, 25 Jun 2002 16:11:01 GMT
I was speaking of the contains(Object) method.

The primitive collections raise a ClassCast when contains("hi")
is invoked on it.  A Predicated collection won't raise a ClassCast
when contains("hi") is invoked and the Predicate doesn't allow
Strings.  It just returns false.

So, the primitive collections "fail fast" on those operations.
I'm not using the term in the usual sense of Iterator fail-fast
behavior.  I think it was Ola who first used "fail fast" and
"permissive" to describe the two different approaches to the
contains(Object) method recieving invalid input.

I'm saying I'd like to see consistency in the behavior of a
primitive collection's contains(Object) and a Predicated
collection's contains(Object).

-Paul

> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> Sent: Tuesday, June 25, 2002 9:06 AM
> To: Jakarta Commons Developers List
> Subject: Re: [collection] Collections for primitives
> 
> 
> 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>
> 

--
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