Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 4525 invoked from network); 25 Jun 2002 16:03:06 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 25 Jun 2002 16:03:06 -0000 Received: (qmail 26535 invoked by uid 97); 25 Jun 2002 16:03:12 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 26507 invoked by uid 97); 25 Jun 2002 16:03:11 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 26489 invoked by uid 98); 25 Jun 2002 16:03:11 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-ID: <006101c21c62$43a73700$375822d9@oemcomputer> From: "Stephen Colebourne" To: "Jakarta Commons Developers List" References: Subject: Re: [collection] Collections for primitives Date: Tue, 25 Jun 2002 17:06:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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" To: "'Jakarta Commons Developers List'" 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: > > For additional commands, e-mail: > > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: > -- To unsubscribe, e-mail: For additional commands, e-mail: