Hi, 2012/7/9 Sébastien Brisard <[email protected]>: > HI, > > 2012/7/9 Sébastien Brisard <[email protected]>: >> Hello, >> >> 2012/7/9 Luc Maisonobe <[email protected]>: >>> On 09/07/2012 07:08, Sébastien Brisard wrote: >>>> 2012/7/9 Gilles Sadowski <[email protected]>: >>>>> On Sat, Jul 07, 2012 at 01:49:25PM +0200, Sébastien Brisard wrote: >>>>>> Hello, >>>>>> most existing methods in class RealVector allow method chaining. >>>>> >>>>> Chaining does not always make for readable code. >>>>> >>>>>> However, some methods just return void instead of this >>>>>> - addToEntry >>>>>> - set >>>>>> - setEntry >>>>>> - setSubVector >>>>>> - unitize >>>>>> >>>>>> Are you OK with having all or only some (which ones) methods return this? >>>>> >>>>> +0 (for people who like it). >>>>> >>>> I agree, I generally find confusing methods which return {@code this}, >>>> but I have to admit that in this context, a fluent interface is very >>>> useful. >>> >>> I think changing a return value from void to non-void is safe from a >>> compatibility point of view, but I would like to be sure. Does anybody >>> have an advice on it ? >>> >> That's what I would have thought, too. Would a silent clirr report be >> convincing evidence (in which case, I'll try)? >> We would also advertise this change in the release notes. >> Sébastien > > As a follow-up: clirr does report an error. I'm not sure we should > treat it as such, though. I fail to see how this change can lead to > any binary compatibility issue. Will start a thread with a more > focused subject. > Sébastien
It results from http://mail-archives.apache.org/mod_mbox/commons-dev/201207.mbox/%3CCAGRH7HqdLSj65kBeD_tHfSA4%3DQh5BMPqqmNezxfZqZ5qjR%2Be6w%40mail.gmail.com%3E that this change indeed breaks compatibility. I will therefore file a JIRA ticket for 4.0... Sébastien --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
