[Soot-list] JimpleLocal.equals()

[Michael Faes]

Thank you for your answers. If equivTo() is used for things like 
subexpression elimination, the current implementation makes sense. It 
would be nice if this fact was documented, but oh well.

But what about equals()? I use JimpleLocals (or objects that build on 
top of them) in HashSets and -Maps and it's very counter-intuitive to 
have multiple objects with exactly the same structure (and therefore the 
same string representation) in those sets.

Anyway, I just changed the implementation in my copy of Soot and it 
doesn't seem to cause any trouble, so I'm fine. But I think it would be 
more intuitive (meaning less surprising and therefore better) if 
equals() was structure-based and (if desired) the fact that two local 
variables with the same name can be different was reflected in the 
structure.

Michael

-------- Original-Nachricht --------
Betreff: Re: [Soot-list] JimpleLocal.equals()
Von: Ondřej Lhoták <olhotak at uwaterloo.ca>
An: Patrick Lam <p.lam at ece.uwaterloo.ca>
Datum: 28.01.2013 22:31

> Local variables do not have any internal substructure (i.e.
> subexpressions).
>
> equivTo is used for equivalent expressions for the purpose of things
> like common subexpression elimination. Two locals are equivalent if
> and only if they are the same local.
>
> The previous implementation compared the names of the locals. This is
> incorrect in the case when multiple distinct locals have the same name.
> This can arise in Soot for example with the use-original-names option.
>
> Ondřej
>
> On Mon, Jan 28, 2013 at 04:04:40PM -0500, Patrick Lam wrote:
>> Version control history shows me that Ondrej made that change in 2003:
>>
>> plam at polya:~/soot-svn/src/soot/jimple/internal$ svn log -r705
>> ------------------------------------------------------------------------
>> r705 | olhota | 2003-03-02 18:14:13 -0500 (Sun, 02 Mar 2003) | 3 lines
>>
>> Bug fix: equivTo on JimpleLocal's and BafLocal's should be object equality
>> svn merge -r 703:704 $SVN/branches/1.2.5.dev.8
>>
>> I'm not sure why this is the case. Maybe Ondrej remembers. It was 9
>> years ago though.
>>
>> pat
>>
>> On 01/28/2013 03:04 PM, Michael Faes wrote:
>>> Hi everyone,
>>>
>>> I'm currently having problems with the implementation of
>>> JimpleLocal.equals() and equivTo():
>>>
>>> /**
>>>    * Returns true if the given object is structurally equal to this one.
>>>    */
>>> public boolean equivTo(Object o) {
>>>       return this.equals( o );
>>> }
>>>
>>> While the Javadoc says that structural equivalence is tested (which is a
>>> sensible thing to do), actually object identity is tested, as the
>>> equals() method is not overridden (which does not seem to be so
>>> sensible). In addition, the hashCode() method is overridden in a
>>> structure-based way, which (is legal but) makes even less sense to me.
>>>
>>> Does anybody know if there is a reason for all this or can I safely
>>> replace the current equals method with a structure-based one?
>>>
>>> Thanks for your time.
>>> Michael
>>> _______________________________________________
>>> Soot-list mailing list
>>> Soot-list at sable.mcgill.ca
>>> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>>
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>