Array equality?

On Mon, Sep 28, 2009 at 2:41 PM, Miles Sabin <miles [at] milessabin [dot] com> wrote:

Checking out the recent array and collection updates I thought I'd see
if like "foo".reverse.reverse,

 Array(1, 2, 3).reverse.reverse == Array(1, 2, 3)

also does the right thing. Unfortunately it doesn't.

In a similar vein I noticed the following for the first time (this is
unchanged from 2.7.x),

scala> Array(1, 2, 3) == Array(1, 2, 3)
res11: Boolean = false

scala> Array(1, 2, 3) match { case Array(1, 2, 3) => true ; case _ => false }
res12: Boolean = true

Expected? Intended? Unavoidable?

I might remember it wrong, but wasn't the this whole discussions on how Arrays were in fact Java arrays and the equality of java arrays was b0rked?
 

Cheers,


Miles

--
Miles Sabin
tel: +44 (0)7813 944 528
skype:  milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

--
Viktor Klang

Blog: klangism.blogspot.com
Twttr: viktorklang

Lift Committer - liftweb.com
AKKA Committer - akkasource.org
Cassidy - github.com/viktorklang/Cassidy.git
SoftPub founder: http://groups.google.com/group/softpub

On Mon, Sep 28, 2009 at 01:41:23PM +0100, Miles Sabin wrote:
> Array(1, 2, 3).reverse.reverse == Array(1, 2, 3)
>
> also does the right thing. Unfortunately it doesn't.

== on arrays is still AFAIK using reference equality. I expect the plan
is to have it act like the other collections, but if I don't get it for
free with the implementation in sequence then I'll need a pointer from
martin as to where to catch it.

Or come to think of it maybe that's not the plan, since if the java
array hashcode is allowed through unhindered we have the usual troubles.

On Mon, Sep 28, 2009 at 3:55 PM, Paul Phillips wrote:
> Or come to think of it maybe that's not the plan, since if the java
> array hashcode is allowed through unhindered we have the usual troubles.
>
Exactly. Arrays are not sequences, they are just convertible to them.
So they inherit hashCode and equals from Java.

Cheers

Even Java seems to admit they got equals/hashCode wrong for Arrays. Would it be possible to use java.util.Arrays.equals and ju.Arrays.hashCode (note plural Arrays) instead of the inherited equals/hashCode from Object?

--j

On Mon, Sep 28, 2009 at 7:41 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:

On Mon, Sep 28, 2009 at 3:55 PM, Paul Phillips <paulp [at] improving [dot] org> wrote:
> Or come to think of it maybe that's not the plan, since if the java
> array hashcode is allowed through unhindered we have the usual troubles.
>
Exactly. Arrays are not sequences, they are just convertible to them.
So they inherit hashCode and equals from Java.

Cheers

As a justification, it seems weird that Scala in general takes == to mean object equality instead of reference equality, but for == on Arrays goes back to (effectively) using reference equality.

--j

On Mon, Sep 28, 2009 at 4:05 PM, Jorge Ortiz <jorge [dot] ortiz [at] gmail [dot] com> wrote:

Even Java seems to admit they got equals/hashCode wrong for Arrays. Would it be possible to use java.util.Arrays.equals and ju.Arrays.hashCode (note plural Arrays) instead of the inherited equals/hashCode from Object?

--j

On Mon, Sep 28, 2009 at 7:41 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:

On Mon, Sep 28, 2009 at 3:55 PM, Paul Phillips <paulp [at] improving [dot] org> wrote:
> Or come to think of it maybe that's not the plan, since if the java
> array hashcode is allowed through unhindered we have the usual troubles.
>
Exactly. Arrays are not sequences, they are just convertible to them.
So they inherit hashCode and equals from Java.

Cheers

+42

Sent from my iPhone
On Sep 28, 2009, at 7:05 PM, Jorge Ortiz <jorge [dot] ortiz [at] gmail [dot] com> wrote:

Even Java seems to admit they got equals/hashCode wrong for Arrays. Would it be possible to use java.util.Arrays.equals and ju.Arrays.hashCode (note plural Arrays) instead of the inherited equals/hashCode from Object?

--j

On Mon, Sep 28, 2009 at 7:41 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch (martin [dot] odersky [at] epfl [dot] ch" rel="nofollow">martin [dot] odersky [at] epfl [dot] ch)> wrote:

On Mon, Sep 28, 2009 at 3:55 PM, Paul Phillips <paulp [at] improving [dot] org (paulp [at] improving [dot] org" rel="nofollow">paulp [at] improving [dot] org)> wrote:
> Or come to think of it maybe that's not the plan, since if the java
> array hashcode is allowed through unhindered we have the usual troubles.
>
Exactly. Arrays are not sequences, they are just convertible to them.
So they inherit hashCode and equals from Java.

Cheers

 -- Martin

On Tue, Sep 29, 2009 at 1:05 AM, Jorge Ortiz wrote:
> Even Java seems to admit they got equals/hashCode wrong for Arrays. Would it
> be possible to use java.util.Arrays.equals and ju.Arrays.hashCode (note
> plural Arrays) instead of the inherited equals/hashCode from Object?
>
No, unfortunately, because arrays might masquerade as objects. So we
could only do it with a run-time check, which would slow down all
calls to equals and hashCode.

On Tue, Sep 29, 2009 at 2:07 PM, martin odersky wrote:
> On Tue, Sep 29, 2009 at 1:05 AM, Jorge Ortiz wrote:
>> Even Java seems to admit they got equals/hashCode wrong for Arrays. Would it
>> be possible to use java.util.Arrays.equals and ju.Arrays.hashCode (note
>> plural Arrays) instead of the inherited equals/hashCode from Object?
>>
> No, unfortunately, because arrays might masquerade as objects. So we
> could only do it with a run-time check, which would slow down all
> calls to equals and hashCode.

I appreciate that you've just gone through the process of eliminating
a lot of harmful array boxing, but wouldn't it be possible to box
arrays only when they're viewed at Any or AnyRef?

Cheers,

Miles