[scala] Re: The Language Designer's Dilemma

> 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@...
> <mailto: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.
>