Return-Path: 
 <commons-dev-return-94973-apmail-jakarta-commons-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org
Received: (qmail 13827 invoked from network); 4 Nov 2006 01:42:33 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 4 Nov 2006 01:42:33 -0000
Received: (qmail 54072 invoked by uid 500); 4 Nov 2006 01:42:43 -0000
Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org
Received: (qmail 53994 invoked by uid 500); 4 Nov 2006 01:42:43 -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 53983 invoked by uid 99); 4 Nov 2006 01:42:43 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Nov 2006 17:42:43 -0800
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (herse.apache.org: domain of rahul.akolkar@gmail.com
 designates 64.233.182.187 as permitted sender)
Received: from [64.233.182.187] (HELO nf-out-0910.google.com) (64.233.182.187)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Nov 2006 17:42:31 -0800
Received: by nf-out-0910.google.com with SMTP id y25so1681636nfb
        for <commons-dev@jakarta.apache.org>;
 Fri, 03 Nov 2006 17:42:09 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=o23C/XvS927C3qDpEXajnWoN/smIJJOGBS9/Gvadrz8UFT9HlopnsZOoNDNNpflQcPBw5gJU7QxxvLggyKk/dBZUuUvpWUor1vVb8yhfScUymQY7dnNRcV6+AS8w6M0kymBE1SLyIvSFYFMJAKhNFs5nsw9SgOoVEuPTQpj+qzQ=
Received: by 10.78.142.14 with SMTP id p14mr3729610hud.1162604528427;
        Fri, 03 Nov 2006 17:42:08 -0800 (PST)
Received: by 10.78.165.6 with HTTP; Fri, 3 Nov 2006 17:42:08 -0800 (PST)
Message-ID: <ce1f2ea80611031742m6146aef5l5bf165b1c135540a@mail.gmail.com>
Date: Fri, 3 Nov 2006 20:42:08 -0500
From: "Rahul Akolkar" <rahul.akolkar@gmail.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Subject: Re: [collections] Generics & the collection subpackage
In-Reply-To: <454BD4F5.3070004@btopenworld.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4542AE53.3030702@btopenworld.com>
	 <454BD4F5.3070004@btopenworld.com>
X-Virus-Checked: Checked by ClamAV on apache.org

On 11/3/06, Stephen Colebourne <scolebourne@btopenworld.com> wrote:
> There has been reltively little feedback on these backwards incompatible
> changes. Do I assume (by lazy consensus) that [collections-generics]
> will be seriously backwards incompatible? Can I commit changes? Are we
> agreed on the strategy "produce the best API", rather than "produce a
> compatible API".
>
<snip/>

We don't need everyone to agree (assuming commits go to the jdk5 branch).

[collections] has had a good life, perhaps its time for a makeover. I see it as:

a) Produce a lean jdk5 worthy API, remove jdk redundancy, generify
b) There could be a separate exercise to generify with BC, if anyone is upto it
c)  Stare at (a) as [collections-generics/collections5] and (b) as
[collections]++ and decide -- only needed if (b) comes to exist

-Rahul


> Stephen
>
>
> Stephen Colebourne wrote:
> > First analysis of the collection subpackage of [collections] for the
> > generics branch.
> >
> > - BoundedCollection should be deleted/renamed to Bounded
> > new Bounded interface would not implement Collection, allowing it to be
> > implemented by Maps as well as Collections
> >
> > - UnmodifiableBoundedCollection should be deleted
> > Just use the isFull/maxSize methods on CollectionUtils or similar
> >
> > - AbstractSerializedCollectionDecorator should be deleted
> > Serialization can now be rolled up into the base decorator
> > This simplifies a lot of code
> > It wasn't done originally due to back-compat
> >
> > - TransformedCollection will need some thinking about to generify, as a
> > transformer can change object types
> >
> > - Consider adding a Decorator interface
> > This would provide a single method decorated() that obtains the
> > collection that has been decorated.
> > Whilst useful, this is also potentially dangerous exposure of state.
> >
> > - Consider adding a Container interface
> > This would be a base super interface for Collection and Map (but
> > obviously we can't hack the JDK.
> >
> > - Consider whether UnmodifiableCollection should be deleted as it
> > duplicates the JDK.
> >
> > Stephen
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org