Commons Developers List
Subject: RE: [primitives] Package layout strategy
To my knowledge, the type based packaging as presented is not possible.
boolean, byte, short, et al are Java keywords and can not be used as parts
of a package name. So, if a type based approach is to be employed,
convoluted names
: [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
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
]
Sent: 10 October 2003 22:17
To: Jakarta Commons Developers List
Subject: Re: [primitives] Package layout strategy
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
To: Jakarta Commons Developers List
Subject: Re: [primitives] Package layout strategy
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
: [primitives] Package layout strategy
While I can understand how this structure may be convenient, I don't
think it would be the best choice. One of the controlling factors in
packaging is dependencies. Package A depends on Package B depends on
Package C.
For example, in Stephen's suggested
-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
only import the same.
Matt
-Original Message-
From: __matthewHawthorne [mailto:[EMAIL PROTECTED]
Sent: 13 October 2003 16:05
To: Jakarta Commons Developers List
Subject: Re: [primitives] Package layout strategy
I can think of some inheritance in the current structure
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,
The problem is: how to properly package the massive amount of primitive
collection classes. I see this as a valid problem. Leaving well enough
alone is a possibility, another is to discuss if there are better
options. That's what is taking place here.
Waiting until there is a real-world
I've got almost no stake in this (except in having the work move forward
so that I might take advantage of it in the future), but as far as the
maps are concerned, I think having each of the possible pairwise
solutions is overkill.
What is to be served by a map of short -- Object, that isn't
- 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
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
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
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
15 matches
Mail list logo
