[primitives] Package layout strategy

[Stephen Colebourne <sc...@btopenworld.com>]

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

Re: [primitives] Package layout strategy

[__matthewHawthorne <ma...@phreaker.net>]

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

Re: [primitives] Package layout strategy

[Rodney Waldhoff <rw...@apache.org>]

-0 to partitioning by collection or type. Neither is going to be a clean
partitioning.  For a collection counter-example, consider an
ordered set/unique list.   For a type counter-example, consider a map of
chars to ints or ints to booleans, etc.

Similarly, this name-spacing doesn't accurately represent the
relationships between classes.   A class in primitives.list.* is likely to
be more closely bound to classes in primitives.collection and
primitives.iterator than to many other classes in primitives.list.

Also, I'd strongly discourage bundling the adapters into the same package
as the primitive collections.  The adapter classes, being dependent upon
the java.util collections, has a different role, a different set of
dependencies, and to my mind quite logically belongs in a different
(if nested) namespace.

To put it another way, it generally makes a lot of sense to me to have the
package hierarchy represent the dependency hierarchy, so that classes in
a.b.c depend more upon (or have closer relationship to) classes in
a.b than to classes in a.b.d.  Similarly, a class in a.b should only
extremely rarely depend upon a class in a.b.c.

We don't currently have any map-like implementations.  Why don't we wait
to repackage until we have an actual use case for it?  What problem are we
trying to solve?

Also, in the suggested repackaging, where does the stuff currently in
primitives.adapters.io go?

On Fri, 10 Oct 2003, 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
>
>

-- 
- Rod <http://radio.weblogs.com/0122027/>

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