----- "Jake Mannix" <jake.man...@gmail.com> a écrit : > Adding methods to implementations is fine, but not to interfaces - how > would > > that work for client implementations? And everywhere in sight inside > of the > > linear package you have handles on RealVector and RealMatrix, so > you'd > have to cast to concrete implementation to get access to these new > methods...
You are both right. I was mainly refering to removing methods as this affects not only implementations but mainly user code. Adding new methods to interfaces is an incompatible change in the sens that existing implementations need to add this. However, I would be pragmatic here. The odds are very low that someone dared to add his own implementation of such huge interfaces, they are mainly for our own use and they are really new as they were created for 2.0. In addition, we would provide a default implementation for these new methods, so if someone did really create a class that implements RealVector, he would simply have to say it extends AbstractRealVector instead. So there is a clear gain to accept this kind of incompatible change as soon as 2.1. What do other people think about this ? Perhaps we should also deprecate the gazillion maptXxx and ebeXxx methods, I'm not sure. Luc > > On Wed, Oct 14, 2009 at 11:22 PM, Ted Dunning <ted.dunn...@gmail.com> > wrote: > > > I think that Luc was referring to non-backwards compatible changes. > Adding > > methods should not be in this category, but removing them would be. > > > > On Wed, Oct 14, 2009 at 4:49 PM, Jake Mannix > <jake.man...@gmail.com> > > wrote: > > > > > Question about this: if RealVector is locked as an interface - no > changes > > > until > > > 3.0 - and the Matrix and Vector interfaces have method signatures > which > > > take > > > RealVector as an argument, how is adding new methods to an > implementation > > > of RealVector (say AbstractRealVector) going to help anyone? > > > > > > > > > > > -- > > Ted Dunning, CTO > > DeepDyve > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
