You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Felix Schumacher <fe...@internetallee.de> on 2015/12/13 12:01:23 UTC
Usage of final methods in newly added report package
Hi all,
I see a lot of methods in the newly added report package, that are
declared final.
What is the reasoning behind this?
Regards,
Felix
Re: Usage of final methods in newly added report package
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 20.12.2015 um 14:14 schrieb sebb:
> On 20 December 2015 at 10:52, Felix Schumacher
> <fe...@internetallee.de> wrote:
>> Am 13.12.2015 um 14:11 schrieb Philippe Mouawad:
>>> Hi Felix,
>>> Do you have an example where it does not seem justified ?
>> I wondered why they were (and sometimes were not) used.
>>
>> I stumbled upon the usage (or non usage) of final when looking at a findbugs
>> report on CsvSampleWriter. That class uses a overridable method setWriter
>> from its constructor, which findbugs finds "scary".
>>
>> In other classes I found a few methods declared final and other not, without
>> a documentation, why those final classes are closed for further inheritance
>> and the others not.
>>
>> I haven't looked, whether they were justified or not, I was just curious.
> Final is required in some cases, e.g. methods called from constructor
> (*) or parameter passed to nested class.
>
> It is also potentially useful as a way of documenting that an item is
> not intended to be altered (although of course that doesn't stop a
> mutable object from being changed). This can be helpful when trying to
> follow code.
Right, but I think this usage of final should be documented in the class
or methods.
>
> Some people like to make everything possible final; I think that can
> be distracting.
It looked just a bit random to me. All in all I tend to find, that
making parameters final is a good idea (does only local harm), but
making methods final should be done with documentation (is a design
decision for the possible inheritance usages of the class).
Regards,
Felix
>
> (*) if a sub-class overrides the method, it may be called before the
> class has been fully constructed so may fail in unexpected ways.
>
>> Regards,
>> Felix
>>
>>> Thanks
>>>
>>> On Sunday, December 13, 2015, Felix Schumacher <
>>> felix.schumacher@internetallee.de> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I see a lot of methods in the newly added report package, that are
>>>> declared final.
>>>>
>>>> What is the reasoning behind this?
>>>>
>>>> Regards,
>>>> Felix
>>>>
Re: Usage of final methods in newly added report package
Posted by sebb <se...@gmail.com>.
On 20 December 2015 at 10:52, Felix Schumacher
<fe...@internetallee.de> wrote:
> Am 13.12.2015 um 14:11 schrieb Philippe Mouawad:
>>
>> Hi Felix,
>> Do you have an example where it does not seem justified ?
>
> I wondered why they were (and sometimes were not) used.
>
> I stumbled upon the usage (or non usage) of final when looking at a findbugs
> report on CsvSampleWriter. That class uses a overridable method setWriter
> from its constructor, which findbugs finds "scary".
>
> In other classes I found a few methods declared final and other not, without
> a documentation, why those final classes are closed for further inheritance
> and the others not.
>
> I haven't looked, whether they were justified or not, I was just curious.
Final is required in some cases, e.g. methods called from constructor
(*) or parameter passed to nested class.
It is also potentially useful as a way of documenting that an item is
not intended to be altered (although of course that doesn't stop a
mutable object from being changed). This can be helpful when trying to
follow code.
Some people like to make everything possible final; I think that can
be distracting.
(*) if a sub-class overrides the method, it may be called before the
class has been fully constructed so may fail in unexpected ways.
> Regards,
> Felix
>
>>
>> Thanks
>>
>> On Sunday, December 13, 2015, Felix Schumacher <
>> felix.schumacher@internetallee.de> wrote:
>>
>>> Hi all,
>>>
>>> I see a lot of methods in the newly added report package, that are
>>> declared final.
>>>
>>> What is the reasoning behind this?
>>>
>>> Regards,
>>> Felix
>>>
>>
>
Re: Usage of final methods in newly added report package
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 13.12.2015 um 14:11 schrieb Philippe Mouawad:
> Hi Felix,
> Do you have an example where it does not seem justified ?
I wondered why they were (and sometimes were not) used.
I stumbled upon the usage (or non usage) of final when looking at a
findbugs report on CsvSampleWriter. That class uses a overridable method
setWriter from its constructor, which findbugs finds "scary".
In other classes I found a few methods declared final and other not,
without a documentation, why those final classes are closed for further
inheritance and the others not.
I haven't looked, whether they were justified or not, I was just curious.
Regards,
Felix
>
> Thanks
>
> On Sunday, December 13, 2015, Felix Schumacher <
> felix.schumacher@internetallee.de> wrote:
>
>> Hi all,
>>
>> I see a lot of methods in the newly added report package, that are
>> declared final.
>>
>> What is the reasoning behind this?
>>
>> Regards,
>> Felix
>>
>
Re: Usage of final methods in newly added report package
Posted by Philippe Mouawad <ph...@gmail.com>.
Hi Felix,
Do you have an example where it does not seem justified ?
Thanks
On Sunday, December 13, 2015, Felix Schumacher <
felix.schumacher@internetallee.de> wrote:
> Hi all,
>
> I see a lot of methods in the newly added report package, that are
> declared final.
>
> What is the reasoning behind this?
>
> Regards,
> Felix
>
--
Cordialement.
Philippe Mouawad.