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 Sat, 22 Jun 2002 22:05:04 GMT
I agree with Ola's views below. add()s should throw a ClassCastException.
remove()s should be silent. queries should return false. The collection is
just much easier to use that way. And all of this behaviour should be
documented.

Stephen

----- Original Message -----
From: "Ola Berg" <ola.berg@arkitema.se>
To: <commons-dev@jakarta.apache.org>
Sent: Saturday, June 22, 2002 10:50 PM
Subject: Re: [collection] Collections for primitives


> Ola wrote:
> >> Shouldn\\\'t myIntList.contains( \\\"Foo\\\") result in false?
>
> michael wrote:
> >No. The Collection.contains(Object) contract declares that a
> >ClassCastException is thrown \"if the type of the specified element is
> >incompatible with this collection\". \"Foo\" is incompatible with an
> >int collection.
>
> Hmm, looking at the contract for Collection, it seems like it leaves a
> lot for the implementors to decide:
>
> Javadoc for java.util.Collection says:
> ---8<---
> Some collection implementations have restrictions on the elements that
they may contain.
> For example, some implementations prohibit null elements,
> and some have restrictions on the types of their elements.
>
> Attempting to add an ineligible element throws an unchecked exception,
> typically NullPointerException or ClassCastException.
>
> Attempting to query the presence of an ineligible element may throw an
exception,
> or it may simply return false;
> some implementations will exhibit the former behavior and some will
exhibit the latter.
>
> More generally, attempting an operation on an ineligible element whose
completion would
> not result in the insertion of an ineligible element into the collection
may
> throw an exception or it may succeed, at the option of the implementation.
> Such exceptions are marked as \"optional\" in the specification for this
interface.
> --->8---
>
> According to this, the following should be true about the List contract:
>
> //should definitely throw ClassCastException
> myIntList.add( \"Foo\");
> myIntList.add( 12, \"Foo\");
> myIntList.set( 12, \"Foo\");
>
> //might or might not throw ClassCastException
> if (myIntList.contains( \"Foo\")){...
> if (myIntList.indexOf( \"Foo\") != -1){...
> if (myIntList.lastIndexOf( \"Foo\")) != -1){...
> myIntList.remove( \"Foo\");
>
> Since the ClassCastException in the latter four methods are marked as
> \"(optional)\" in the javadocs, we should consider changing the
> implementation or clarifying the javadocs, else the user of the
> classes would have to rely on trial-and-error.
>
> I think that the lookup methods shouldn\'t throw a
> ClassCastException, because that would make it easier for people to
> query a group of collections for the occurence of certain objects in a
> general fashion, without having to deal with the type-safe lists in a
> special (and tedious) way:
>
> if (object instanceof CertainType){
>     certainTypeList.contains( object);
> }
> if (object instanceof CertainType2){
>     certainType2List.contains( object);
> }
>
> etc...
>
> Note that this would be a usable behaviour for any type-safe list.
>
> Next problem is the methods that deals with collections. What I can
> see, the addAll() methods should behave like the add() methods, ie.
> throw a ClassCastException.
>
> I suggest that the containsAll(), removeAll() and retainAll() methods
> don\'t throw a ClassCastException. containsAll() could simply return
> false, and non-throwing removeAll() and retainAll() are useful when
> you have Collections with mixed types as arguments (that would be
> useful in addAll() too, but since such behaviour would break the
> Collection contract...)
>
> And since the removeAll() IMO shouldn\'t throw a ClassCastException,
> remove() shouldn\'t either, for consistency.
>
> michael
> >The throwing of a ClassCastException may not seem \"appropriate\", but
> >it is already documented in the Collection contract (and also the
> >List contract and Map contract). There is no reason to \"fix\" it
> >because it follows the contract. Added documentation restating the
> >documentation in Collection and List is doable, but not necessary in
> >my opinion.
>
> Since the contract states that there are room for
> different implementation we should consider it. Either way, the path
> chosen should be documented.
>
> This isn\'t really about collections for primitives, but about
> type-safe collections as a whole. I suggest that the strict behaviour
> (throwing ClassCastExceptions) should be implemented as asserting
> wrappers around the collection. The collection itself should chose the
> permissive approach when the contract leaves room for it.
>
> /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>


Mime
View raw message