commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: [primitives] branch policy
Date Sun, 19 Mar 2006 17:14:08 GMT
On Sat, 2006-03-18 at 22:44 +0000, Stephen Colebourne wrote: 
> robert burrell donkin wrote:
> > happier developing at joda or would you prefer see that code as the
> > basis for a commons primitives 2?
> It could be commons primitives 2, but as the API would be rather 
> different it would seem difficult to explain to our users. Having the 
> separate codebase would thus seem to make sense.
> > had it in mind to introduce a lighter IntMap interface and to provide an
> > adapter to map. that's the way the rest of commons primitives works. but
> > i'm pretty agnostic: equally happy to extend Map.
> With the design you are thinking of, commons seems best.

i was only thinking that way since it seemed to fit in best with the way
that primitives is designed :) 

sourceforge is timing out so i can't take a look at the joda stuff

what i'm interested in are efficient ways to index objects. 

int maps are a little unusual because they are the same as sparse
arrays. so from one perspective they are just lists with lots of nulls
whereas from another they are maps with integral keys. the map contract
is overly heavy in places and an interchangeable lighter interface would
make sense for applications requiring better performance.

> > perhaps it might be possible to create code that could easily be added
> > to both repositories. worth looking into?
> The joda code uses code-generation to create all the 8 types of 
> primitives from velocity templates. I always felt this was a better way 
> to manage code such as primitives. As such though, the codebases have 
> very little in common, so I suspect trying to write one codebase would 
> be difficult.

not sure that generation be possible with the maps i have in mind in any

sandy's right that really the implementations are actually likely to
just be lists accepting nulls tuned for sparse data sets. the various
interfaces would be fitted on top for convenience and

perhaps i'm missing why the order of the interface inheritance is a big
deal but i can't connect to sourceforge (times out) to take a look at
the joda-primitives.

- robert

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message