HI,
2012/7/9 Sébastien Brisard <sebastien.bris...@m4x.org>:
> Hello,
>
> 2012/7/9 Luc Maisonobe <luc.maison...@free.fr>:
>> On 09/07/2012 07:08, Sébastien Brisard wrote:
>>> 2012/7/9 Gilles Sadowski <gil...@harfang.homelinux.org>:
>>>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
