commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From __matthewHawthorne <ma...@phreaker.net>
Subject Re: [primitives] Object/JDK integration - was Proposed interface changes
Date Thu, 06 Nov 2003 17:44:28 GMT
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


Mime
View raw message