[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Method.equals()
From: |
Mark Wielaard |
Subject: |
Method.equals() |
Date: |
19 Feb 2002 23:28:14 +0100 |
Hi,
I am going through the patches that the Orp developers submitted to
Classpath. The following patch to Method puzzles me:
2001-12-17 Wu Gansha <address@hidden>
* vm/reference/java/lang/reflect/Method.java: Reimplemented
equals(), refined toString().
Index: vm/reference/java/lang/reflect/Method.java
===================================================================
RCS file:
/home/gwu2/cvs/classpath/classpath/vm/reference/java/lang/reflect/Method.java,v
retrieving revision 1.4
diff -w -r1.4 Method.java
145c145,161
< return this == o;
---
> if (o == null)
> return false;
> if (!(o instanceof Method))
> return false;
> Method m = (Method)o;
> if(!name.equals(m.getName()))
> return false;
> if(!declaringClass.equals(m.getDeclaringClass()))
> return false;
> Class[] params1 = getParameterTypes();
> Class[] params2 = m.getParameterTypes();
> if(params1.length != params2.length)
> return false;
> for(int i = 0; i < params1.length; i++)
> if(params1[i] != params2[i])
> return false;
> return true;
Why/When is this neccessary? The comment to equals says:
Two Methods are semantically equivalent if they have the same declaring
class, name, and parameter list. This ignores different exception
clauses, but since you can't create a Method except through the VM,
this is just the == relation.
So this comment is wrong for Orp, but when does this happen?
Maybe we should just mark this method "native" in Classpath and
leave it to the VM implementor.
Cheers,
Mark
- Method.equals(),
Mark Wielaard <=