If your structure was to be used, I would suggest putting a "collections" package in between primitives and the type. This may be needed for separation of primitive collection code and other possible primitive utils.
For example, "o.a.c.primitives.collections.int" instead of "o.a.c.primitives.int", to keep miscellaneous int classes from being lumped in with the collections.
I see your points, especially about ease of use, although I can't say that the need to import more packages makes something harder to use. Harder in terms of keystrokes, yes... and maybe that's what it all comes down to anyway.
If done your way, I would actually prefer the Maps to be put in with the rest of that type's collections. I don't see a reason why a Map would require its own package but a List wouldn't.
I'm starting to not feel strongly either way, I think there are fairly good arguments for both structures. Maybe it's time for some others to chime in...
So the battle has become:
o.a.c.primitives.boolean o.a.c.primitives.byte o.a.c.primitives.short o.a.c.primitives.int o.a.c.primitives.long o.a.c.primitives.float o.a.c.primitives.double
vs.
o.a.c.primitives.collection o.a.c.primitives.list o.a.c.primitives.iterator o.a.c.primitives.map
Any other opinions?
Hope, Matthew wrote:
(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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
********************************************************************** **** 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
********************************************************************** **** 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
**************************************************************************
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
