Ok, back on list with this then (Thanks Danny for reminding us to deal with this perennial issue we have!)
On Wed, Apr 14, 2010 at 2:26 AM, Sean Owen (JIRA) <j...@apache.org> wrote: > > Yeah let's take some time to get this right. At the moment I see four > notions of equivalence in Vector (which is down from five!), and this seems > like one too many: > > ==: of course > equals(): compares values, names, not implementation > equivalent(): compares values only > strictEquivalence(): compares values, names, implementation > I like that summary, nice and concise. > equals() ought to be strict-ish. Its current implementation is fine, though > conventional wisdom is that it's better to only consider instances of the > same class equals() in order to avoid transitivity problems. I think that's > a valid concern here. > What is the transitivity problem? If (a instanceof VClassA), (b instanceof VClassB) and (c instanceof VClassC), if all three equals() methods compare the same things (ie values, names, not implementation), then a.equals(b) && b.equals(c) ==> a.equals(c), right? > Therefore I submit that equals() should be replaced with what > strictEquivalence() does. > > (And then, of course, fix the underlying issue that was raised too!) > I would actually prefer ripping names out of the base vectors entirely. They should decorate the mathematical vector, but as their use is decidedly non-mathematical and application specific (we basically don't use them at all currently, it should be noted, and remember the YAGNI principle...), keeping them in the base mahout-math vector classes seems wrong. If they weren't in the base class at all, we could have just == : ref check equals : check values, not impl -jake
