Google Groups

Re: Symmetry of Box's equals method

Jan Ouwens Mar 2, 2012 4:23 AM
Posted in group: Lift
Hi David,

Thanks for your answer. I appreciate the historical perspective!

I'm not sure if adding Comparable would really help, since you would
be imposing an ordering that's not really there. (I mean, is an Empty
box "more than" or "less than" a Failure box?) It might make sense if
the object it contains is also comparable, but I doubt if it's
possible to make that work without losing symmetry again. I'm not sure
what the semantics would be if the contained object isn't comparable.

This sounds like a typical thing to add to the long list of nice-to-
haves for the next big backward-compatibility-breaking rewrite version
of 20X6. Although I think it would help to simply make it a little
more explicit in the ScalaDoc. It already says "Determines equality
based upon the contents of this Box instead of the box itself." Maybe
it can be expanded into something like "Determines equality based upon
the contents of this Box instead of the box itself; as a result, it is
not symmetric. Take care when mixing Boxes and their values in
collections." Or something to that effect.


On Mar 1, 10:55 pm, David Pollak <>
> On Thu, Mar 1, 2012 at 1:07 PM, Jan Ouwens <> wrote:
> > Hi all,
> > I was playing around with Lift a bit (I'm using it in a new project)
> > when I found something unexpected in the net.liftweb.common.Box class;
> > namely that its equals method is not symmetric. See this gist for a
> > test that shows the problem:
> > If foo and boxedFoo are supposed to be equal, then I would expect the
> > second and third test to both pass; if they are not, then I would
> > expect both tests to fail. Either way, I expect the first test to
> > pass.
> > The equals method can be made symmetric pretty easily by removing the
> > second case in the equals method (case (Full(x), y) => x == y). But
> > doing so will probably break lots of existing code :), so it may not
> > be the way to go.
> > I'm not sure what best to do with this, as it looks like a design
> > decision to have this special case in the equals method, but at the
> > very least I thought I should mention it here.
> Back 4 years ago when I wrote Box, Scala took == a lot less seriously and
> played fast and loose with non-symmetrical ==.  I'm not sure I made a
> formal design decision, as much as a "hey, this is easy and as long as I'm
> here..."  And as you point out changing things now would likely be a silent
> breaking change, and thus would be anti-desirable.
> Perhaps we should add java.lang.Comparable to Box: That'd give us a nice way to
> truly compare items.  What do you think?
> Thanks,
> David
> > Regards,
> > Jan
> > --
> > Lift, the simply functional web framework:
> > Code:
> > Discussion:
> > Stuck? Help us help you:
> >
> --
> Visi.Pro, Cloud Computing for the Rest of Us
> Lift, the simply functional web framework
> Follow me:
> Blog: