You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Sébastien Brisard <se...@m4x.org> on 2012/07/07 13:49:25 UTC
[math] Fluent interface in RealVector
Hello,
most existing methods in class RealVector allow method chaining.
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?
Best regards,
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Fluent interface in RealVector
Posted by Sébastien Brisard <se...@m4x.org>.
Hi,
2012/7/9 Sébastien Brisard <se...@m4x.org>:
> HI,
>
> 2012/7/9 Sébastien Brisard <se...@m4x.org>:
>> Hello,
>>
>> 2012/7/9 Luc Maisonobe <Lu...@free.fr>:
>>> On 09/07/2012 07:08, Sébastien Brisard wrote:
>>>> 2012/7/9 Gilles Sadowski <gi...@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
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Fluent interface in RealVector
Posted by Sébastien Brisard <se...@m4x.org>.
HI,
2012/7/9 Sébastien Brisard <se...@m4x.org>:
> Hello,
>
> 2012/7/9 Luc Maisonobe <Lu...@free.fr>:
>> On 09/07/2012 07:08, Sébastien Brisard wrote:
>>> 2012/7/9 Gilles Sadowski <gi...@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
Re: [math] Fluent interface in RealVector
Posted by Sébastien Brisard <se...@m4x.org>.
Hello,
2012/7/9 Luc Maisonobe <Lu...@free.fr>:
> On 09/07/2012 07:08, Sébastien Brisard wrote:
>> 2012/7/9 Gilles Sadowski <gi...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Fluent interface in RealVector
Posted by Luc Maisonobe <Lu...@free.fr>.
On 09/07/2012 07:08, Sébastien Brisard wrote:
> 2012/7/9 Gilles Sadowski <gi...@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 ?
Luc
> Sébastien
>>
>> [And for API consistency.]
>>
>>
>> Gilles
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Fluent interface in RealVector
Posted by Sébastien Brisard <se...@m4x.org>.
2012/7/9 Gilles Sadowski <gi...@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.
Sébastien
>
> [And for API consistency.]
>
>
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Fluent interface in RealVector
Posted by Gilles Sadowski <gi...@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).
[And for API consistency.]
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org