commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hope, Matthew" <Matthew.H...@capitalone.com>
Subject RE: [primitives] Package layout strategy
Date Mon, 13 Oct 2003 13:55:20 GMT
Is this really the case?

The problem of primitives is that inheritance becomes impossible for a
collection/map
Like api with strongly typed parameters and returns.

Despite that fact that the IntArraylist and LongArrayList will almost
certainly have exactly the same code but s/int/long s/Integer/Long they
stand no chance of inheriting much useful behaviour/state since it would
require an Object or Number to be of any use and the goal of primitives is
surely for a combination of type safety / speed / size

What dependency would/should exist between an IntArrayList and
DoubleArrayList?

Also this structure would allow deployment (should someone so desire) of
just the primitives they are interested in...

For the collection classes I think this holds true. For Map classes I'm not
certain but do you really want a Map package with every combination of x ->
y where x elementof {byte, short, char, int, long, float, double, Object}
and y elementof {boolean, byte, short, char, int, long, float, double,
Object}

Which is every realistically useful combination... (a boolean keyed HashMap
being not terribly useful or efficient)

I make this 71 classes (Object -> Object removed) again with no dependency
on the set *package* but with particular dependency on the one or two
primitive packages

E.g. a long -> double Map would depend (for keySet() and values()
respectively) on the Set implementation of long and Collection
implementation of double but no others.

This structure would _reduce_ inter-package dependency

If this was being done with Objects then this would all be bad since there
would be obvious areas for inheritance, this is just not the case for
primitives.

Matt

-----Original Message-----
From: __matthewHawthorne [mailto:matth@phreaker.net] 
Sent: 13 October 2003 14:23
To: Jakarta Commons Developers List
Subject: Re: [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 structure, it's likely that 
o.a.c.primitives.list  and o.a.c.primitives.map will depend on 
o.a.c.primitives.collection.  Your suggested structure will cause a lot 
of criss-crossing dependencies between packages, and I think that this 
will make the code harder to manage and stabilize.




Hope, Matthew wrote:
> As a user I would point out that a likely use case would involve one 
> primitive type but lots of different collections of that type.
> 
> Would packaging by type work?
> 
> I know it has negatives but if most of the code will be done via a 
> template and code generation that it wouldn't be too bad perhaps?
> 
> Would mean you import o.a.c.primitives.int.*; and get all the 
> collections / Map and iterators there ready in your ide of choice :¬)
> 
> Just a thought and I haven't really considered the ramifications in 
> much detail.
> 
> Matt
> 
> -----Original Message-----
> From: __matthewHawthorne [mailto:matth@phreaker.net]
> 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 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>  
> **********************************************************************
> ****
> The information transmitted herewith is sensitive information intended
only
> for use by the individual or entity to which it is addressed. If the
reader
> of this message is not the intended recipient, you are hereby notified
that
> any review, retransmission, dissemination, distribution, copying or other
> use of, or taking of any action in reliance upon this information is
> strictly prohibited. If you have received this communication in error,
> please contact the sender and delete the material from your computer.


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
 
**************************************************************************
The information transmitted herewith is sensitive information intended only
for use by the individual or entity to which it is addressed. If the reader
of this message is not the intended recipient, you are hereby notified that
any review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message