What's the performance cost here? Equality checks are something that happen, well, a lot!
The canEqual approach copes quite nicely here. The JVM can swallow these methods whole, inlining stuff and removing entire lengths of unused code in a quest for ever more speed. Reflection, on the other hand, is notoriously slow... On 17 October 2010 09:16, Reinier Zwitserloot <[email protected]> wrote: > ... because that's just not in List.java, and changing interfaces is > not a backwards compatible change. > > Putting that method into a class doesn't scale. List isn't the only > thing that uses equals. If I create one method for every equals-using > class out there, I'll end up with 5000 methods. > > On Oct 17, 9:38 am, Miroslav Pokorny <[email protected]> > wrote: > > Why cant use generate a method that uses a some function to take two > Lists > > and compare them element by element, rather than having one list try and > > compare against the other list... I guess you want a "Comparator" to be > > passed to the List etc just like TreeSet takes a Comparator before > falling > > back on Comparable. > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- Kevin Wright mail / gtalk / msn : [email protected] pulse / skype: kev.lee.wright twitter: @thecoda -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
