commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sébastien Brisard <sebastien.bris...@m4x.org>
Subject Re: [math] Fluent interface in RealVector
Date Mon, 09 Jul 2012 06:58:01 GMT
HI,

2012/7/9 Sébastien Brisard <sebastien.brisard@m4x.org>:
> Hello,
>
> 2012/7/9 Luc Maisonobe <Luc.Maisonobe@free.fr>:
>> On 09/07/2012 07:08, Sébastien Brisard wrote:
>>> 2012/7/9 Gilles Sadowski <gilles@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message