Re: Equality of Locals in Soot Version 1.beta.4

[Patrick LAM <plam@sable.mcgill.ca>]

On Fri, 9 Apr 1999, James C. Corbett wrote:

> >From beta.3 to beta.4, the definition of equals() for Locals seems to
> have changed.  In beta.3, Locals were not equal() unless they were the 
> same Local, while in beta.4, Locals seems to test equal() if they have 
> the same name, even if they are distinct locals in different methods.
> 
> Was there a reason for this change?  
> 
> I am storing Locals in a Hashtable (using the Local as the key), but
> the change in equals() breaks this.  I could generate a unique key for
> a Local from the names of the class, method, and local, but I'm
> wondering if this is a bug?

Yes, this was changed in order to permit aggregation (the Grimp stuff).  
Two locals are equal in the aggregation sense if they have the same 
name.  However, I'm never trying to aggregate locals in different methods.

Unfortunately, the Local does not know which method and class it belongs 
to, and I don't think it should.  They were not testing equal previously, 
because different Locals always had different hashCodes, because they 
were separately allocated.  I don't think that's a meaningful notion of 
equality in this case.

My opinion (impartial as always) is that Locals should be equal if they have 
the same name and type, since that's all they know about.

pat