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>
Message-ID: <3FAA887C.4030803@phreaker.net>
Date: Thu, 06 Nov 2003 09:44:28 -0800
From: __matthewHawthorne <matth@phreaker.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.5) Gecko/20031014 Thunderbird/0.3
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [primitives] Object/JDK integration - was Proposed interface
 changes
References: <004901c3955d$c4410b00$264a8151@oemcomputer>
 <20031105104206.P6465@minotaur.apache.org>
 <012001c3a400$75c97c80$c32b8051@oemcomputer>
In-Reply-To: <012001c3a400$75c97c80$c32b8051@oemcomputer>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

This is a tough one.  I've gone back and forth a few times, but I think 
I prefer the sandbox approach.

In general, I like the idea of being able to create an ArrayIntList and 
use it as an IntList, List, or Collection.  I find this easier and more 
efficient that having to create an adapter such as 
IntCollectionCollection or IntListList.

I think that with a good interface -> abstract class -> implementation 
heirarchy (which [primitives] already has in a lot of places), this 
won't complicate the work needed to implement a primitive collection by 
much.

Overall, I think this would make the API easier to use and understand.


Stephen Colebourne wrote:
> As people may or may not be aware, the sandbox contains an implementation of
> primitive collections that works differently from [primitives].
> 
> * [primitives] (commons-proper) - IntCollection is a top-level interface in
> its own right. A wrapper is needed to integrate with JDK Collection.
> * primitives-sandbox - IntCollection extends Collection in the JDK.
> 
> These are two entirely different approaches to the problem space. Here are
> the reasons why I prefer the sandbox approach:
> - Integration - an IntCollection IS a JDK Collection, no extra wrappers
> needed
> - Number of classes - Because it is a JDK Collection, no wrappers or
> adaptors are needed
> - Possible to implement multiple collections in one class, ie. a class could
> implement both IntCollection and ShortCollection.
> Main downside:
> - Methods are named differently from JDK Collection in places because of
> return type issues
>   * intInterator()
>   * toIntArray()
>   * removeInt()
>   * getInt(index)
> 
> The benefits of the commons-proper approach appear to be:
> - Simpler API for IntCollection et al, no confusion with Object world
> - Methods are named exactly as per the JDK collection (except remove)
> - Simpler implementation for each class, as it focuses on one task
> - Theory of relatively low interaction between primitive collections and
> object ones?
> Main downside:
> - Object and JDK integration - keeps Object and primitive worlds separate,
> which goes against the [primitives] charter in my mind.
> 
> 
> This thread allows for one final debate as to the best approach for
> primitives design. We may decide its now too late for commons-proper as it
> has a release, or we may not.
> 
> If we decide to stay with the [primitives] commons-proper architecture, I
> hereby commit to remove the commons-sandbox code from the CVS to non ASF (or
> rename it if people express a desire to keep it).
> 
> 
> Finally, this thread started when I proposed a toCollection() method for
> IntCollection et al, and a toList() method for IntList. If we keep the
> commons-proper design we should examine these methods as to whether they are
> not the bare minimum for Object/JDK integration.
> 
> Stephen
> 
> 
> From: "Rodney Waldhoff" <rwaldhoff@apache.org>
> 
>>>New interface PCollection (or PrimitiveCollection):
>>>- toCollection()
>>>It should be really easy to get a JDK collection from a [primitives]
> 
> one.
> 
>><Type>CollectionCollection.wrap(my<type>collection) does this already.
>>I'd be OK with adding a convenience method somewhere, though I'm not sure
>>PrimitiveCollection is the right place for it.  (Perhaps
>>PrimitiveCollections.toCollection(<Type>Collection): Collection?)


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