Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (herse.apache.org: domain of flamefew@gmail.com designates
 64.233.182.186 as permitted sender)
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=rnxCfABEuOpzH+e6r0IGuVRB+DCjgqv+F+Kf3SxTPcI/1M+m5odJ5U+J9gshRfHOfxqJ/AiowqUIpyKw7tuZo+kdiNgdyuGzdUYtgg3SClyOtDxa6gPGHeXfZXywLa4Z+yI2ezuFjzBXDFQinNNONjA1CjACUiGIKr3W1QCYxTI=
Message-ID: <31cc37360610272306xf0a4027o431ac826dae8c6eb@mail.gmail.com>
Date: Fri, 27 Oct 2006 23:06:38 -0700
From: "Henri Yandell" <flamefew@gmail.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Subject: Re: [collections] Generics & the collection subpackage
In-Reply-To: <4542AE53.3030702@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>

On 10/27/06, Stephen Colebourne <scolebourne@btopenworld.com> 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.

Should we delete the EMPTY_MAP, EMPTY_COLLECTION, EMPTY_SET bits?
They're in the JDK now.

Maybe we should create a JIRA issue for all the things that should be
deleted as being in the JDK. Store them up there and take care of them
if we decide that we're going to aggressively break backwards compat.

Hen

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