You may feel that the primitives code was "passed over for release for no particularly good reason", but the community disagreed. There were a lot of reasons discussed, and many developers chimed in with their opinions. The consensus seemed to be that the primitive code should be moved to another project. I think we should accept it and move on.
There are some packaging issues that have yet to be solved, releasing the current [primitives] code as v1.0 may cause some deprecation and backwards compatibility headaches if changes occur (and it seems that they will.) I think the best decision is to release the current code as 0.1, and think about possible improvements and additions for 1.0.
Rodney Waldhoff wrote:
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
