I like the immutability idea. I wonder if there are any guidelines on when the performance hit because of immutability is high enough to want mutable objects and synchronization?
-Ajo On Thu, Aug 15, 2013 at 10:27 AM, Gilles <gil...@harfang.homelinux.org>wrote: > On Thu, 15 Aug 2013 11:07:20 -0500, Phil Steitz wrote: > >> On Aug 15, 2013, at 7:31 AM, Gilles <gil...@harfang.homelinux.org> wrote: >> >> On Wed, 14 Aug 2013 23:40:58 +0100, sebb wrote: >>> >>>> On 14 August 2013 23:34, Gilles <gil...@harfang.homelinux.org> wrote: >>>> >>>>> >>>>> At this point, I'd tend to think that creating a copy of trunk in the >>>>> Commons's "sandbox" part of the repository will be more productive. >>>>> >>>> >>>> Why sandbox? Just use a temporary branch in the existing math repo. >>>> >>> >>> Has Evan the permissions to commit there? >>> >> >> No, but same is true of the Sandbox unless he is already an ASF >> committer. Sebb's point is that temp branches in svn can be used for >> this. >> > > Hmm; isn't there a place where no committer could be given privileges > to write to the repository? > > >> It's also fine to just look at his stuff in GitHub for now, IMO. >> >> > As we discussed in the few last posts, the "stuff" is not complete; > it is only the realization of the "potentialities" that would it > worth replacing the currnet code. > > Personally, I was expecting this issue to be moved forward, i.e. evolve > the design until it actually (i.e. in code) meets all the expected > improvements. > But I won't have time to fill in all the blanks (Javadoc, formatting, > naming, unit tests porting) for this to be committed in trunk. > I was hoping that we can work in real-time with Evan; meaning: he > would create the bulk of the code, then I (and anyone interested) > can comment on those aspects that would IMHO need polishing, then > he could commit additions and modifications. > So that in the end we can commit top trunk the whole contribution > without fear that some tedious and time consuming work will be needed > afterwards.[1] > > > Gilles > > [1] Cf. "BOBYQAOptimizer"; (efficient and maintainable) porting is > still far from finished even after tens of hours spent on it. > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org> > For additional commands, e-mail: dev-h...@commons.apache.org > >
