-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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- - Rod <http://radio.weblogs.com/0122027/> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
