Well this simple question threw up some debate :-) The debate over packages raises a question over the ambition of the [primitives] component. I am looking to add additional Map, and maybe Set, implementations to [primitives]. I have needed a int/Object and Object/int map on more than one occasion, so I believe that there is a good case for coding it in [primitives]. I don't believe this has to be before the 1.0 release, although it would be nice.
As has been pointed out, the complete combination of Maps leads to a lot of classes. See http://pcj.sourceforge.net/docs/api/index.html. This should not greatly concern us however, as we should be code generating the combinations. Although many may be less useful, the overhead is small once code generation is adopted. What is significant is being able to grasp the component quickly. Different people do this in different ways. I am in the camp that prefers lots of smaller packages of related classes. I do not concern myself greatly with inter-package connections because IMO the Java language does not have the scoping rules to make such restrictions possible or worthwhile. (If Java had a friend scope, or a subpackage scope my views might be different.) --- Of the proposed solutions: 1) Named after the primitive type, eg. o.a.c.primitives.boolean Fails because you can't name packages with a keyword, and its not great for maps. 2) All in one. I really dislike this because the package will be ridiculously large, and a new user won't be able to navigate it. 3) Split by collection/adaptor/decorator. This works up to a point, but breaks down due to size in a similar way. 4) Grouped by interface. My choice. This wins for me because a new user arriving at the component can see instantly what interfaces are supported simply by looking at package names. It also means that the top level package is left free for static utilities which often get lost otherwise. I have no problem with the list package extending the collection package. o.a.c.primitives.collection o.a.c.primitives.collection.adaptor (or adaptor.collection?) o.a.c.primitives.collection.decorator (or decorator.collection?) o.a.c.primitives.list o.a.c.primitives.iterator o.a.c.primitives.map o.a.c.primitives.iterator o.a.c.primitives.listiterator o.a.c.primitives.hash o.a.c.primitives.comparator o.a.c.primitives.io Stephen ----- Original Message ----- From: "Rodney Waldhoff" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Sent: Monday, October 13, 2003 6:07 PM Subject: Re: [primitives] Package layout strategy > On Mon, 13 Oct 2003, __matthewHawthorne wrote: > > > I believe that there will be a lot of code generation involved, Stephen > > checked in some Velocity templates a few weeks ago. > > Rather than generating the 64 pairwise primitive-to-primitive maps, their > associated iterfaces, base classes, adapaters, decorators (immutable, > sychronized) and variations (ordered/unordered, hash/tree, etc.), why not > wait until we have an actual, real-world application that calls for them? > > > 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? > > > > Yes, leave well enough alone. Again, what problem are we trying to solve? > > -- > - Rod <http://radio.weblogs.com/0122027/> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
