Return-Path: 
 <commons-dev-return-99926-apmail-jakarta-commons-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org
Received: (qmail 73204 invoked from network); 12 Mar 2007 21:10:17 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 12 Mar 2007 21:10:17 -0000
Received: (qmail 31784 invoked by uid 500); 12 Mar 2007 21:10:23 -0000
Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org
Received: (qmail 31730 invoked by uid 500); 12 Mar 2007 21:10:23 -0000
Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:commons-dev-unsubscribe@jakarta.apache.org>
List-Help: <mailto:commons-dev-help@jakarta.apache.org>
List-Post: <mailto:commons-dev@jakarta.apache.org>
List-Id: "Jakarta Commons Developers List" <commons-dev.jakarta.apache.org>
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Delivered-To: mailing list commons-dev@jakarta.apache.org
Received: (qmail 31719 invoked by uid 99); 12 Mar 2007 21:10:23 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Mar 2007 14:10:23 -0700
X-ASF-Spam-Status: No, hits=2.0 required=10.0
	tests=HTML_MESSAGE
X-Spam-Check-By: apache.org
Received-SPF: pass (herse.apache.org: local policy)
Received: from [12.11.148.122] (HELO relay2.ptc.com) (12.11.148.122)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Mar 2007 14:10:10 -0700
Received: from hq-ex3fe2.ptcnet.ptc.com ([132.253.201.63])
  by relay2.ptc.com with ESMTP; 12 Mar 2007 17:09:21 -0400
X-IronPort-AV: i="4.14,275,1170651600";
   d="scan'208,217"; a="206481732:sNHT944793518"
Received: from [132.253.11.87] ([132.253.11.87]) by HQ-EX3FE2.ptcnet.ptc.com
 with Microsoft SMTPSVC(6.0.3790.1830);
	 Mon, 12 Mar 2007 17:09:21 -0400
Message-ID: <45F5C19D.1030808@ptc.com>
Date: Mon, 12 Mar 2007 16:09:49 -0500
From: Jess Holle <jessh@ptc.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [collections] VOTE: Collections-java5 direction
References: 
 <OF4306C1E4.980E77D0-ON8725729C.0069C257-8725729C.006D7D00@fs.fed.us>
In-Reply-To: 
 <OF4306C1E4.980E77D0-ON8725729C.0069C257-8725729C.006D7D00@fs.fed.us>
Content-Type: multipart/alternative;
 boundary="------------030408010400040104090105"
X-OriginalArrivalTime: 12 Mar 2007 21:09:21.0782 (UTC)
 FILETIME=[B4902960:01C764EA]
X-Virus-Checked: Checked by ClamAV on apache.org

--------------030408010400040104090105
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Bryce L Nordgren wrote:
> Jess Holle <jessh@ptc.com> wrote on 03/12/2007 12:28:34 PM:
>   
>> You can always get the current unchecked behavior with
>>     
> Collection<Object>.
>
> Thing 1:
> ========
> Ummm.  The fact that the above statement is incorrect is precisely why
> Java5 generics syntax is dangerous.  Collection<Object> is not considered a
> supertype of any other typed Collection, and is therefore not
> interchangeable with other typed collections.  (e.g. you can't pass it
> around like you would a Collection)
>
> To treat the elements of the collection as you always have, one needs
> Collection<Object>, as above.
> To treat the collections themselves as you always have, one needs
> Collection<?>.
>
> However, if you have a collection which is a supertype of all other
> collections, you cannot add any elements to it because the single legal
> element type for that collection is unknown.
>
> Thing 2:
> ========
> I don't want the old unchecked behavior.  I want checked behavior,
> commons-collections style.  Commons-collections can handle mixed element
> types, where every element has bounds on its types.  Generics do not even
> contain a way to express "this collection is potentially composed of a
> mixture of elements, but every element is guaranteed to be between {Parent}
> and {Child} in the class hierarchy".  In order to implement this type of
> checked behavior, Java Generics requires that we use the "unchecked"
> syntax.  I guess we should call it "implementation-defined type checking".
> My plea is not intended to start a war over Java generics, but to beg that
> current functionality not be abandonded merely because Java Generics cannot
> adequately describe it.
>   
You can express the bounds of <? extends A super B>, right?  There's 
even a more obscure syntax for expressing something that extends 
multiple classes in cases.

Nothing is perfect, but Java 5 generics seem to strike a good balance.  
Having constraints to express every nuance would kill usability.

You could always use something like Josh Bloch's heterogeneous type-safe 
container pattern if you need something more.

--
Jess Holle


--------------030408010400040104090105--