Re: equality questions

On Mon, Sep 21, 2009 at 8:10 PM, Seth Tisue wrote:
>>>>>> "martin" == martin odersky writes:
>
>  martin> So, let's try this. I am very hopefull it will work out OK.
>
> To me it seems disturbing, to say the least, to have a language where
> the answer to x == y depends on other factors besides simply what the
> values of x and y are at runtime.

Unfortunately, that's already the case for Java, and we can't do good
interop while not inheriting that property.

> In the scheme you're proposing you
> can get different answers for the same values, depending on what the
> compiler thinks the static types of x and y are.
>
> In case anyone's not following this, in 2.7 we have:
>
> scala> 5 == 5.0
> res0: Boolean = true
>
> scala> (5: Any) == (5.0: Any)
> res1: Boolean = true
>
> Under Martin's proposal as I understand it, the former will remain true
> by virtue of overloads, but the latter will become false.  This has all
> sorts of practical consequences, for example in 2.7 we have:
>
> scala> List(5.0) contains 5
> res5: Boolean = true
>
> but with Martin's proposal it'll be false, because we will no longer
> have a single answer to the question, are 5 and 5.0 equal?  Instead the
> answer will be "it depends".  While I can't claim to understand all
> of the other considerations involved here, this "it depends" seems
> like a big step backwards to me.
>
Well it's that or break the equals/hashcode contract. Choose your poison...

Cheers

> To me it seems disturbing, to say the least, to have a language where
> the answer to x == y depends on other factors besides simply what the
> values of x and y are at runtime.

object x = "hello";
object y = new StringBuilder().Append("hello").ToString();

x != y

string x2 = (string)x;
string y2 = (string)y;

x2 == y2

C# sets a precedent for this too.

On Mon, Sep 21, 2009 at 11:53 AM, martin odersky wrote:
> On Mon, Sep 21, 2009 at 8:10 PM, Seth Tisue wrote:
>> To me it seems disturbing, to say the least, to have a language where
>> the answer to x == y depends on other factors besides simply what the
>> values of x and y are at runtime.
>
> Unfortunately, that's already the case for Java, and we can't do good
> interop while not inheriting that property.

I'm really not convinced of this in this particular case.

Can you give us an example of how changing the rules for x == y for
numeric types in Scala source would affect interoperability with Java?
Yes, behaviour would be different, but it takes more than just a
difference in behaviour for there to be a detrimental impact on
interop. Are there any particular coding patterns which are common now
and which would lead to silent and hard to diagnose breakage if the
change were made?

Cheers,

Miles