On 5 March 2012 12:45, Gilles Sadowski <gil...@harfang.homelinux.org> wrote: > On Mon, Mar 05, 2012 at 01:17:18PM +0100, Sébastien Brisard wrote: >> 2012/3/5 sebb <seb...@gmail.com>: >> > 2012/3/5 Sébastien Brisard <sebastien.bris...@m4x.org>: >> >> Le 5 mars 2012 09:57, Sébastien Brisard <sebastien.bris...@m4x.org> a >> >> écrit : >> >>> Hi, >> >>> I would like to make the following addition to the FieldElement<T> >> >>> interface: >> >>> T divide(int n) >> >>> which would formally be defined as >> >>> this.divide(n) = this.divide(this.getOne().multiply(n)). >> >>> >> >>> This would simplify some expressions, eg integration of polynomials (a >> >>> * x**k becomes a / (k+1) * x ** (k+1)). >> >>> >> >>> What do you think? >> >>> Sébastien >> >> >> >> Please note that the change would hardly be noticeable, as many of the >> >> classes implementing FieldElement already implement divide(int). >> >> Sébastien >> > >> > Also, adding a method to an interface is binary compatible. >> > It is not source compatible. >> > >> > Sebastian >> > >> Ooops. >> That's true. I guess I'll have to postpone this one until 4.0... Sorry >> about that... >> Let me rephrase that: would you *in principle* agree with this new >> feature? If that's OK, I could file a (very long term) JIRA ticket (to >> be fixed in 4.0). > > It's nowhere written that major releases should be few and far between.
It's binary compatibility that is vital. Breaking source compatibility is not generally as disruptive, and has been done before now in minor releases (obviously should not be done in a point release). However, if the required source changes are very extensive, it might warrant a major release. In this case, it's unlikely to require many (if any) changes to source code. If the test code needs changing as a result of changing the interface, that should give a clue (assuming proper coverage). > > Gilles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
