[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: Making == symmetric?

Mark Wilson

10/1/2003 6:35:00 PM


On Wednesday, October 1, 2003, at 02:16 PM, Marcin 'Qrczak' Kowalczyk
wrote:

[snip]

> This is like saying "my programming model is unable to describe the
> reality accurately, so let's change the reality to make it fit the
> model".
>
> For me this is simply a shortcoming in the traditional
> single-dispatched
> OO way of thinking, that it can't make the meaning of == depend on the
> types of both arguments.
>
> I don't say that the language should enforce == to be symmetric. I say
> that the language should allow to define a symmetric == with the
> desired
> meaning.
>
> [snip]

I think Ruby does allow one to define a symmetric ==. As a general
matter, I think a language is only required to enforce a symmetric ==
for objects of the same class (or values of the same type) in order to
have algebraic closure.

Regards,

Mark
1 Answer

Marcin 'Qrczak' Kowalczyk

10/1/2003 6:56:00 PM

0

W li?cie z ?ro, 01-10-2003, godz. 20:34, Mark Wilson pisze:

> I think Ruby does allow one to define a symmetric ==.

Only if you agree to limit cases of "different class but equal" to those
where both classes know each other. Because otherwise you would have to
change the implementation of == in other classes which were already
written elsewhere.

For example there doesn't seem to be a way to add a numeric type which
plays well with other numeric types wrt. ==, including numeric types you
don't know about.

> As a general
> matter, I think a language is only required to enforce a symmetric ==
> for objects of the same class (or values of the same type) in order to
> have algebraic closure.

I prefer to trust the programmer in this case. The only sensible way I
imagine in which the language could enforce a symmetric == is to execute
the programmer-provided equality in both directions and throw error if
they disagree, and this is too little benefit (catching rare bugs) for
too much cost (performance of a common operation). Turning the
disagreement into false or true would mask an error, so it only
discovers bugs - it doesn't add functionality.

--
__("< Marcin Kowalczyk
\__/ qrczak@knm.org.pl
^^ http://qrnik.knm.org.p...