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:28:06 GMT
Yes, I remember arguing before in this thread that false was more useful
than an exception for contains(Object). Also -1 for indexOf() and false for
remove(). So yes I would like to see the primitive collections changed.

Stephen

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


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


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