Yes, AbstractList's solution was to disallow the creation of a ColouredList, or, at least one where an empty red list must equal an empty blue list.
That's a crappy restriction though - it would have been nicer if AbstractList didn't preclude you from writing such a thing. The idea stated in my OP seems like a simple, no-hassle strategy to remove this constraint. On Oct 17, 12:03 pm, A McDowell <[email protected]> wrote: > On Sun, Oct 17, 2010 at 7:06 AM, Reinier Zwitserloot > <[email protected]>wrote: > > > What we really need is for AbstractList's equals() method to be > > intelligent enough to realize if 'other' is a subclass of AbstractList > > that isn't adding any state that is relevant for equality, in which > > case it can do its comparison as usual, or, if 'other' is a subclass > > that DOES add state relevant for equality, such as a color property. > > If that is the case, AbstractList's equals method should conclude > > immediately with: Not equal, even if the contents are. > > Won't this violate symmetry? The equals contract for AbstractList is defined > by java.util.List. > > http://download.oracle.com/javase/6/docs/api/java/util/List.html#equa...) > > An implementation of List that does not do this would equal any ColoredList -- 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.
