RichString

On Sat, May 09, 2009 at 09:15:40AM -0700, Jorge Ortiz wrote:
> Have we given up hope of reasonable behavior for this case?

You did not know I reopened #1495 yesterday to make sure this doesn't
get lost in the shuffle - interesting that makes at least three of us
(also Seth) who tested it immediately after the big commit.

https://lampsvn.epfl.ch/trac/scala/ticket/1495

Thinking about equality and toString lately, it seems like a lot of our
troubles come from not having a reliable layer of indirection between
the methods on j.l.Object (and java's Array) and the methods we use from
scala. Sometimes an intervening layer is there (boxing, implicit
conversions) sometimes it isn't, and that assures us of corner cases at
best and outright brokenness at worst. Implicits make it hard to even
anticipate where all these corner cases will arise - arrays have been
full of fun surprises.

So what if == and friends called into the standard equals by default,
but if either side of the comparison implemented some special designated
method, it would insert a call to that instead? And the same with
toString. Or if that's too radical, simply defining an === method which
did that would give people who care about these things a better option.

I feel like many bugs and inconsistencies could be conquered this way,
but I may be hopelessly naive.

"All problems in computer science can be solved with an additional layer
of indirection."

On Sat, May 9, 2009 at 6:15 PM, Jorge Ortiz wrote:
> I see our old friend:
>
>   "101" == "101".reverse
>
> still equals false.
>
> At some point (a long time ago) there was talk that the new collections
> library would be able to address this, but I don't see how the new
> collections are any more amenable to fixing this than the old ones.
>
> Have we given up hope of reasonable behavior for this case?
>
No, but it's not done yet. We need to treat RichStrings as boxed
strings, the same way we treat BoxedArrays as arrays. That's a change
in the compiler rather than the collection libraries.

Cheers

On Sat, May 09, 2009 at 10:39:20PM +0200, martin odersky wrote:
> No, but it's not done yet. We need to treat RichStrings as boxed
> strings, the same way we treat BoxedArrays as arrays. That's a change
> in the compiler rather than the collection libraries.

Ah. Okay, that was both easier and more specialcased than I anticipated.

scala> "bob" == "bob".reverse
res0: Boolean = true

So how might we feel about generalizing that process so it can be
influenced without hacking the compiler?

On Sat, May 9, 2009 at 7:51 PM, Paul Phillips wrote:
> On Sat, May 09, 2009 at 09:15:40AM -0700, Jorge Ortiz wrote:
>> Have we given up hope of reasonable behavior for this case?
>
> You did not know I reopened #1495 yesterday to make sure this doesn't
> get lost in the shuffle - interesting that makes at least three of us
> (also Seth) who tested it immediately after the big commit.
>
>  https://lampsvn.epfl.ch/trac/scala/ticket/1495
>
> Thinking about equality and toString lately, it seems like a lot of our
> troubles come from not having a reliable layer of indirection between
> the methods on j.l.Object (and java's Array) and the methods we use from
> scala.  Sometimes an intervening layer is there (boxing, implicit
> conversions) sometimes it isn't, and that assures us of corner cases at
> best and outright brokenness at worst.  Implicits make it hard to even
> anticipate where all these corner cases will arise - arrays have been
> full of fun surprises.
>
> So what if == and friends called into the standard equals by default,
> but if either side of the comparison implemented some special designated
> method, it would insert a call to that instead? And the same with
> toString.  Or if that's too radical, simply defining an === method which
> did that would give people who care about these things a better option.
>
> I feel like many bugs and inconsistencies could be conquered this way,
> but I may be hopelessly naive.

No, I think that's precisely what we have to do. We do it already so that
a java.lang.Float(1.0) is the same as a java.lang.Double(1.0). We now
have to add
cases for arrays (because they now have by-element equality) as well as strings.

Cheers