jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: UnmodifiableJMeterVariables implementation
Date Sun, 23 Jul 2017 14:55:12 GMT
I was thinking about some user code or 3rd party plugins currently does
this comparison to detect a change on JMeterVariables
but I think it cannot happen and would be anyway broken by the Unmodifiable
aspect.
So ok for me.


On Sun, Jul 23, 2017 at 4:50 PM, Felix Schumacher <felix.schumacher@
internetallee.de> wrote:

> Am 23.07.2017 um 16:48 schrieb Philippe Mouawad:
>
>> Hi Felix,
>> I agree current behaviour is inconsistent.
>>
>> Can there be a case where we need
>>
>> unmodifiable.equals(vars) == true
>> vars.equals(unmodifiable) == true
>>
> I hope not :)
>
> Felix
>
>
>
>> Regards
>>
>> On Sun, Jul 23, 2017 at 4:45 PM, Felix Schumacher <
>> felix.schumacher@internetallee.de> wrote:
>>
>> Hi all,
>>>
>>> I wonder if the implementation for 'equals', 'hashCode' and possibly
>>> 'toString' of UnmodifiableJMeterVariables are correct.
>>>
>>> I think - for symmetry and since they are not the same classes - the
>>> methods 'hashCode' and 'equals' should include a test for the class.
>>>
>>> Currently with:
>>>
>>>   JMeterVariables vars = somehowGetThem();
>>>   UnmodifiableJMeterVariables unmodifiable = new
>>> UnmodifiableJMeterVariables(vars);
>>>
>>> we have
>>>
>>>   unmodifiable.equals(vars) == true
>>>   vars.equals(unmodifiable) != true
>>>
>>> and
>>>
>>>   unmodifiable.hashCode() == vars.hashCode()
>>>
>>> I think we should have
>>>
>>>   unmodifiable.equals(vars) != true
>>>   vars.equals(unmodifiable) != true
>>>
>>> and
>>>
>>>   unmodifiable.hashCode() != vars.hashCode()
>>>
>>> What do you think?
>>>
>>>   Felix
>>>
>>>
>>>
>>>
>>
>


-- 
Cordialement.
Philippe Mouawad.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message