A Fresh Look at Comparisons, Take 2

[Henning Hasemann]

"Janice Caron" <caron800 at googlemail.com> wrote:
> On 18/04/2008, Henning Hasemann <hhasemann at web.de> wrote:
> >  - You can still not build partially ordered classes at all? (Ie
> >   something similar to complex numbers) Is there a rationale for
> > this?
> 
> Only that Paul said it wasn't necessary, and, on reflection, his logic
> is reasonable.
> 
> Basically, I think the reasoning is... what's the point? After all, if
> c and d are complex numbers, then
> 
>     if (c < d)
> 
> could easily be rewritten as
> 
>     if (c.im == 0 && d.im == 0 && c.re < d.re)

so 2i >= 5 would hold?
The point is that you might want to create structures that are more
complex and not that linear ordered. Think of sets or something.
Naturally one can get around this by building up just "normal methods"
for comparsion, but there might be casess where its just more beautiful
to do it with comparsion operators.

> >  - You can still have opCmp say two objects are equal and opEqual
> > say they're not? (or vice versa, respectively)
> 
> Sure. You can also define opAdd() to do subtraction. Sometimes, you
> just have to rely on common sense.

Sure but then a + b is (for a and b always your type) always
substraction. I don't really see a problem in that you can do stuff
which doesnt make much sense, I just want to say that this shows that
the current notation is not only redundant (regarding ==) but also not
as powerful as it could be (regarding partial ordering).

> (Also, there are rare circumstances where you might want to do that
> deliberately, so that, for example, an AA can contain duplicate
> "equal" keys).

Well I think circumstances where you want partial ordering are more
common ;)

Henning

-- 
GPG Public Key:
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xDDD6D36D41911851