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 < >> [email protected]> 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.
