Given that a version of the code in question was passed over for release in commons-collections 2.0 for no particuarly good reason and has been complete, stable and in production use in its current form for the past 9 months, why don't we release what we have now as commons-primitives 1.0 and pick up this debate for the 2.0 release?
On Tue, 14 Oct 2003, Stephen Colebourne wrote: > 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] > > -- - Rod <http://radio.weblogs.com/0122027/> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
