I'm not sure I follow your reasoning. Surely whether it's tricky or not is completely independent of whether it's in Rocks or directly in Equals?
On May 18, 11:38 am, Jb Evain <[email protected]> wrote: > Thing is that there's a lot of things that could be tricky. So I'd > rather provide an EqualityComparer for MemberReference and > TypeReference in Mono.Cecil.Rocks, than override Equals and > GetHashCode is the object model. > > > > On Tue, May 18, 2010 at 9:37 AM, Jan <[email protected]> wrote: > > +1 > > > And the same for FieldReference, I have a lot of comparisons between > > field access and field defitinion. > > > Maybe there is a common way to implement it. > > > Jan > > > On 17 Mai, 09:07, Timwi <[email protected]> wrote: > >> I have run into a case where I have two separate TypeReference objects > >> that actually refer to the same constructed type (namely, > >> List<string>). Would it be advisable to override the .Equals() method > >> so that they would compare as equal? > > >> -- > >> -- > >> mono-cecil > > > -- > > -- > > mono-cecil > > -- > Jb Evain <[email protected]> > > -- > -- > mono-cecil -- -- mono-cecil
