« Return to Thread: [scala] The Language Designer's Dilemma

Re: [scala] Re: The Language Designer's Dilemma

by Sean McDirmid :: Rate this Message:

Reply to Author | View in Thread

Is it really that easy? Strings in Java are almost primitives, in spite of their java.lang.String exterior. We would still have issues with AnyRef strings coming in, equality wouldn't work where the user might expect it to, and it might be too slow. This is really related to the scala.Array problem: it breaks down in many cases where the compiler cannot detect where boxing is needed.

But if you think scala.String is the right way, you should explore it in more detail, see what the drawbacks are in addition to the benefits. If you can't find drawbacks, then you haven't been thorough enough :) (Never trust any analysis with too many + and not enough -).

Sean

On Sat, May 31, 2008 at 4:13 PM, Jesper Nordenberg <megagurka@...> wrote:

> What was
the Scala team smoking when they decided RichString.reverse should return anything other than String? Of course it should be changed to return String so equality works right! Oh wait...reverse is defined in Seq to return a Seq, and the LUB of String and Seq is...AnyRef. So if reverse in RichString returns a String, then either reverse has to be removed from Seq, or it has to be defined to return AnyRef, or some compiler magic has to make String a Seq (in much the same way that arrays are) introducing more boxing madness to Scala (and equality would still be broken!).

Actually not much compiler magic is needed, just make string literals be of class scala.String (which would be a Seq) and provide implicit conversions to and from java.lang.String.

 « Return to Thread: [scala] The Language Designer's Dilemma