helping out on "%d".format

On Wed, Nov 25, 2009 at 4:36 PM, Paul Phillips wrote:
> With respect to:
>
>  http://lampsvn.epfl.ch/trac/scala/ticket/2694
>
> How do we feel about the following patch? The only good argument against
> as far as I can see is performance, and if you're that worried about it
> I doubt you're using StringLike.format by way of implicit conversion.
>
The patch looks good to me. I don't think format is usually
performance critical, and in any case the umwrapArg code should be
only a small fraction of what format has to do anyway. So I am all for
it.

Cheers

As a general question, is there any reason scala.math.BigDecimal does not extend java.math.BigDecimal?

On Wed, Nov 25, 2009 at 9:36 AM, Paul Phillips <paulp@improving.org> wrote:

With respect to:

 http://lampsvn.epfl.ch/trac/scala/ticket/2694

How do we feel about the following patch? The only good argument against
as far as I can see is performance, and if you're that worried about it
I doubt you're using StringLike.format by way of implicit conversion.

Summary version if it's "tl;dr" is: with a single type test on arguments
to format we can make it so BigInt and BigDecimal (and any other scala
numeric types we might write) are not fat runtime errors.  I could
parameterize ScalaNumber so underlying returns the right type but I
decided it was overkill.



diff --git a/src/library/scala/collection/immutable/StringLike.scala b/src/library/scala/collection/immutable/StringLike.scala
index 37440d7..3d6f3ad 100644