This is a followup to this question: Lambda expression not returning expected MemberInfo
class Human
{
public string name { get; set; }
}
class Man : Human
{
}
var m1 = typeof(Human).GetProperty("name");
var m2 = typeof(Man).GetProperty("name");
//m1 != m2 why?
The same holds for MethodInfos.
I can understand there has to be a difference when Human is an interface, or when name of Human is abstract/virtual. But why is it so for sealed types? Isn't name of Man exactly name of Human?
Clarification: As Jon says their ReflectedTypes are different. ReflectedType in equality should come handy when deciding equality of interface members or overridden members since they are different. But I don't think it should be considered for deciding equality of simple cases like above. May be the design team wanted to be consistent. Just wondering what rationale drove framework designers to consider ReflectedType property in deciding equality of same member spanning over multiple classes.
They differ in their
ReflectedTypeproperty:So if you print out
m1.ReflectedType, it should printHuman. If you print outm2.ReflectedType, it should printMan.EDIT: In terms of why the equality operator is implemented this way: it's always a delicate design decision to work out what
==should mean, in the case where there may be distinguishable but not "primary" differences between objects. This is where providing differentIEqualityComparerimplementations is useful, but of course that doesn't work for the operators themselves.In general, if
x == yis true then it's quite unusual forx.Footo be different toy.Foofor any property. I can't immediately think of any cases where that occurs in the framework.