Re: [primitives] branch policy
On Sat, 2006-03-18 at 22:44 +, 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 case. 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 interchangeability. 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [primitives] branch policy
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. 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. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [primitives] branch policy
On Fri, 2006-03-17 at 00:25 +, Stephen Colebourne wrote: > robert burrell donkin wrote: > >>A release was suggested, but there is no-one around to actually do it. > > > > what actually needs doing? > > (other than the mechanics, of course) > > [primitives] is a strange component. I am the de facto maintainer as its > linked to collections, yet I disagree with the fundamental design > decisions of the component. So much so I started Joda-Primitives (which > I never had the itch to release...) happier developing at joda or would you prefer see that code as the basis for a commons primitives 2? > (If you were bored you could look at the original discussions and you'd > find Rodney was the main instigator of the component and that the design > changed at one point initially with my consent and then I changed my mind) thanks: i'll try to track this stuff down > Anyway, thats the history lesson, and we are where we are. I haven't > looked at your IntMap class, but if it extends Map then it probably > belongs in Joda-Primitives, if it doesn't extend Map then it belongs in > commons-primitives. 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. perhaps it might be possible to create code that could easily be added to both repositories. worth looking into? > As for the release, well I believe that just needs doing. But even I'm > not sure of the current state of the code in there. Perhaps we could > raise Rodney if he's still at Apache? i haven't noticed any posts by him for quite a while. maybe i'll do some digging... > Basically however, its not my itch beyond minor website updates. ok - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [primitives] branch policy
robert burrell donkin wrote: A release was suggested, but there is no-one around to actually do it. what actually needs doing? (other than the mechanics, of course) [primitives] is a strange component. I am the de facto maintainer as its linked to collections, yet I disagree with the fundamental design decisions of the component. So much so I started Joda-Primitives (which I never had the itch to release...) (If you were bored you could look at the original discussions and you'd find Rodney was the main instigator of the component and that the design changed at one point initially with my consent and then I changed my mind) Anyway, thats the history lesson, and we are where we are. I haven't looked at your IntMap class, but if it extends Map then it probably belongs in Joda-Primitives, if it doesn't extend Map then it belongs in commons-primitives. As for the release, well I believe that just needs doing. But even I'm not sure of the current state of the code in there. Perhaps we could raise Rodney if he's still at Apache? Basically however, its not my itch beyond minor website updates. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [primitives] branch policy
On Tue, 2006-03-14 at 23:51 +, Stephen Colebourne wrote: > robert burrell donkin wrote: > > the int map stuff has been stalled for the last week but i hope to be > > able to get back on track sometime this week. i know that a new > > primitives release is pencilled in without int map but i'd like to get > > the API's out there for feedback without waiting too long. > > > > i see a couple of reasonable options: > > > > 1 create a release branch now for the upcoming primitives release > > 2 add int maps into contrib > > A release was suggested, but there is no-one around to actually do it. what actually needs doing? (other than the mechanics, of course) > As such I suspect that your int map stuff will be complete before a > release happens. that depends: given the scope and the amount of time i have free, it's likely to be several weeks before i have the implementations i want. the last attempt to release JCL 1.1 failed due to lack of interest but i haven't given up. IMO it's worth doing since it fixes much of the existing mess. since my plan to cut an alpha for testing failed. > That said, there is no harm in tagging primitives now, enabling a branch > to be taken from the tag. (or are svn branches/tags different from cvs) in subversion: all are one and one is all :) do a 'copy with history': if it ends up in tags then it's a tag, if it ends up in branches, it's a branch. this makes things much, much easier. no tag is necessary with subversion (it's easy enough to take a copy from the revision before the int map stuff gets committed) but IMO it's neater that way. so, i'll take a tag. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [primitives] branch policy
robert burrell donkin wrote: the int map stuff has been stalled for the last week but i hope to be able to get back on track sometime this week. i know that a new primitives release is pencilled in without int map but i'd like to get the API's out there for feedback without waiting too long. i see a couple of reasonable options: 1 create a release branch now for the upcoming primitives release 2 add int maps into contrib A release was suggested, but there is no-one around to actually do it. As such I suspect that your int map stuff will be complete before a release happens. That said, there is no harm in tagging primitives now, enabling a branch to be taken from the tag. (or are svn branches/tags different from cvs) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[primitives] branch policy
the int map stuff has been stalled for the last week but i hope to be able to get back on track sometime this week. i know that a new primitives release is pencilled in without int map but i'd like to get the API's out there for feedback without waiting too long. i see a couple of reasonable options: 1 create a release branch now for the upcoming primitives release 2 add int maps into contrib perferences? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
