commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hope, Matthew" <Matthew.H...@capitalone.com>
Subject RE: [primitives] Package layout strategy
Date Mon, 13 Oct 2003 16:33:49 GMT
(note - I prefer IntList, IntArrayList, IntLinkedList but will go with your
names for consistency and I'm not too fussed)

I agree that Maps will likely require a subpackage since they have such a
vast difference (both in size, complexity and structure) but still think
that should be sub packaged into int -> *, long -> *, etc (since x -> hash
functions can then be in the right package)

Yes there is interface inheritance and implementation but this will all be
within the same package in my suggestion which I view as better.

Normally packages are used to group commonality

That commonality is measured in several ways

Commonality of use (why import x.* is popular irrespective of the rights or
wrongs of it)
Commonality of purpose ("here's a bunch of classes to do X" normally the
package is a namespace and nothing more)

Commonality of dependency (internally x uses y so put them in the same
package for ease of coding, deployment and development)

Commonality of code (x and y both do the same thing so make parent class z
putting them in the same package or z in the parent package to them both
seems reasonable)

In the collections API there is much commonality in all areas such that they
are all in one package. Therefore is seems initially reasonable to do the
same for primitive collections.

However this would make a huge package which, if done in UML, would look
like:

---------  --------------   --------------
|IntList|<-|IntCollection|<-|ArrayIntList|
---------  --------------   --------------
                  ^
                  |
           -------------- 
           |LinkedIntList|
           -------------- 

Plus a separate tree for long, byte etc...

With Objects instead of primitives you could put extends links all over the
place closing these together but due to primitives there will be none of
these.

The only commonality you could add would be putting it into columns with
headings "Maps", "Lists" etc... I believe the other commonalities win out,
especially the use one. 

Despite the fact that, to the eye, the code will seem very similar is not -
IMHO, a good reason to be in the same package. In good OO design commonality
of structure normally means inheritance is / or should be used as such the
argument for a package in this direction (X and all subclasses of X) is
valid. Since there is no inheritance the real driving reason for this
structure goes away.

The unit tests will be, as for the classes - done by code generation surely?
(if you can build the code you can certainly build the test).

It sounds harsh but in this case the development should entirely be done by
machine - so the package structure should be amenable to the user more than
the developer...

If anyone is willing to hand code these classes fair play to them but it
seems a bad route to go down.

My suggestion is

o.a.c.primitives.X
All X collections, all X iterators
o.a.c.primitives.X.map
All X -> * maps, all X -> map entry iterators, any utilities such as hash
generator functions

An X -> Y map need only import the parent package and the Y package

A Map test case need only import the same. 

Matt


-----Original Message-----
From: __matthewHawthorne [mailto:matth@phreaker.net] 
Sent: 13 October 2003 16:05
To: Jakarta Commons Developers List
Subject: Re: [primitives] Package layout strategy


I can think of some inheritance in the current structure, such as:
collection.IntCollection -> list.IntList -> list.ArrayIntList

Although you may have a point about the primitive classes not partaking 
in much interitance.

It all depends on how you define the commonality between the classes: Do 
all primitive Map implementations have more in common than all of the 
classes that deal with ints?  My vote is yes.

The structure of the class and tests for an IntList and an IntMap 
probably won't be very similar.  For me, this is the most important 
factor when designing a package layout.  I think a package that consists 
of all Maps will be easier to manage than a package consisting of all 
int collections, lists, maps, iterators, and sets.




Hope, Matthew wrote:
> Is this really the case?
> 
> The problem of primitives is that inheritance becomes impossible for a 
> collection/map Like api with strongly typed parameters and returns.
> 
> Despite that fact that the IntArraylist and LongArrayList will almost 
> certainly have exactly the same code but s/int/long s/Integer/Long 
> they stand no chance of inheriting much useful behaviour/state since 
> it would require an Object or Number to be of any use and the goal of 
> primitives is surely for a combination of type safety / speed / size
> 
> What dependency would/should exist between an IntArrayList and 
> DoubleArrayList?
> 
> Also this structure would allow deployment (should someone so desire) 
> of just the primitives they are interested in...
> 
> For the collection classes I think this holds true. For Map classes 
> I'm not certain but do you really want a Map package with every 
> combination of x -> y where x elementof {byte, short, char, int, long, 
> float, double, Object} and y elementof {boolean, byte, short, char, 
> int, long, float, double, Object}
> 
> Which is every realistically useful combination... (a boolean keyed 
> HashMap being not terribly useful or efficient)
> 
> I make this 71 classes (Object -> Object removed) again with no 
> dependency on the set *package* but with particular dependency on the 
> one or two primitive packages
> 
> E.g. a long -> double Map would depend (for keySet() and values()
> respectively) on the Set implementation of long and Collection 
> implementation of double but no others.
> 
> This structure would _reduce_ inter-package dependency
> 
> If this was being done with Objects then this would all be bad since 
> there would be obvious areas for inheritance, this is just not the 
> case for primitives.
> 
> Matt
> 
> -----Original Message-----
> From: __matthewHawthorne [mailto:matth@phreaker.net]
> Sent: 13 October 2003 14:23
> To: Jakarta Commons Developers List
> Subject: Re: [primitives] Package layout strategy
> 
> 
> While I can understand how this structure may be convenient, I don't
> think it would be the best choice.  One of the controlling factors in 
> packaging is dependencies.  Package A depends on Package B depends on 
> Package C.
> 
> For example, in Stephen's suggested structure, it's likely that
> o.a.c.primitives.list  and o.a.c.primitives.map will depend on 
> o.a.c.primitives.collection.  Your suggested structure will cause a lot 
> of criss-crossing dependencies between packages, and I think that this 
> will make the code harder to manage and stabilize.
> 
> 
> 
> 
> Hope, Matthew wrote:
> 
>>As a user I would point out that a likely use case would involve one
>>primitive type but lots of different collections of that type.
>>
>>Would packaging by type work?
>>
>>I know it has negatives but if most of the code will be done via a
>>template and code generation that it wouldn't be too bad perhaps?
>>
>>Would mean you import o.a.c.primitives.int.*; and get all the
>>collections / Map and iterators there ready in your ide of choice :¬)
>>
>>Just a thought and I haven't really considered the ramifications in
>>much detail.
>>
>>Matt
>>
>>-----Original Message-----
>>From: __matthewHawthorne [mailto:matth@phreaker.net]
>>Sent: 10 October 2003 22:17
>>To: Jakarta Commons Developers List
>>Subject: Re: [primitives] Package layout strategy
>>
>>
>>Looks good.  This will present a nice, easy way to navigate through
>>all
>>of the classes.
>>
>>
>>
>>
>>Stephen Colebourne wrote:
>>
>>
>>
>>>I've been thinking about how the new project should structure its 
>>>packages.
>>>
>>>[primitives] will (I hope) be looking at Map implementations in 
>>>addition to the List ones currently existing. I would like to 
>>>restructure the packages into an interface based scheme.
>>>primitives.collection  primitives.list
>>>primitives.map
>>>primitives.iterator
>>>Each package would contain the interface, implementation, wrapper and
>>>adaptor.
>>>
>>>I believe this will give [primitives] the room it needs to grow, and 
>>>allow users a quick grasp of the features available. (If you want to 
>>>see what this turns out like see the sandbox primitives)
>>>
>>>However, this is a change from the current layout of the code held in 
>>>[collections]. So.... I propose that
>>>- the primitive classes in [collections] are imported directly into
>>>[primitives] without changing the package name
>>>- we arrange a snapshot build of [primitives] using this package 
>>>structure
>>>- we reorganize the packages into the new layout
>>>- we head towards a release
>>>
>>>How does this sound???
>>>
>>>Stephen
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>> 
>>**********************************************************************
>>****
>>The information transmitted herewith is sensitive information intended
> 
> only
> 
>>for use by the individual or entity to which it is addressed. If the
> 
> reader
> 
>>of this message is not the intended recipient, you are hereby notified
> 
> that
> 
>>any review, retransmission, dissemination, distribution, copying or 
>>other use of, or taking of any action in reliance upon this 
>>information is strictly prohibited. If you have received this 
>>communication in error, please contact the sender and delete the 
>>material from your computer.
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>  
> **********************************************************************
> ****
> The information transmitted herewith is sensitive information intended
only
> for use by the individual or entity to which it is addressed. If the
reader
> of this message is not the intended recipient, you are hereby notified
that
> any review, retransmission, dissemination, distribution, copying or other
> use of, or taking of any action in reliance upon this information is
> strictly prohibited. If you have received this communication in error,
> please contact the sender and delete the material from your computer.


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
 
**************************************************************************
The information transmitted herewith is sensitive information intended only
for use by the individual or entity to which it is addressed. If the reader
of this message is not the intended recipient, you are hereby notified that
any review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.

---------------------------------------------------------------------
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