scalac, mind your own tuple business

Oh my...is there a workaround?

No pimpin' for that bad-boy library!
I think we have no other choice, it has to be a wrap-and-delegate job...

I've suggested a few improvements here:
https://lampsvn.epfl.ch/trac/scala/ticket/3583#comment:3

scalac could be changed to either disable auto-tupling, or at least
emit a warning if:

- the target method is defined in Java
- the target method is one of a set of overloaded alternatives
- the user enables a command line flag, -Xdisable-auto-tupling
-Xwarn-auto-tupling.

-jason

On Sun, Jul 11, 2010 at 11:25 PM, Paul Phillips wrote:
> There is this library joda time which I'd always heard nice things about
> so I set out to use it today.  Let me show you something.
>
> scala> import org.joda.time._
> import org.joda.time._
>
> scala> def time = new DateTime(2010, 5, 7, 0, 0, 0, 0)
> time: org.joda.time.DateTime
>
> scala> time
> res0: org.joda.time.DateTime = 2010-05-07T00:00:00.000-07:00
>
> scala> def time = new DateTime(2010, 5, 7, 0, 0, 0)
> time: org.joda.time.DateTime
>
> scala> time
> java.lang.IllegalArgumentException: No instant converter found for type: scala.Tuple6
>        at org.joda.time.convert.ConverterManager.getInstantConverter(ConverterManager.java:165)
>        at org.joda.time.base.BaseDateTime.(BaseDateTime.java:169)
>
> This is a DEBACLE!
>
> The joda time constructors include one which takes Object.  That means
> you lose 100% of your type safety unless you luck into a conflict it
> will notice, because scala thinks "oh, you must have meant to call the
> Object constructor with a 6-tuple, let me help you."
>
> No scala buddy, I didn't mean that.
>
> I knew this risk existed but now having experienced it in this way I
> consider it past indecent.  I think we must do something.
>
> --
> Paul Phillips      | A Sunday school is a prison in which children do
> Future Perfect     | penance for the evil conscience of their parents.
> Empiricist         |     -- H. L. Mencken
> i pull his palp!   |----------* http://www.improving.org/paulp/ *----------
>

Oh, wait, I didn't look closely enough at the example.  I assume you specified the wrong number of arguments for the DateTime constructor in the second definition of time, so scalac happily tried to find a way to make it the right number of arguments.  So when one would expect a compile error due to the wrong number of arguments, one receives runtime error because scalac tuplized your arguments into a single object.
Not pretty but not the end of the world.

Man, my brain is slow today.

On Sun, Jul 11, 2010 at 5:28 PM, Erik Engbrecht <erik [dot] engbrecht [at] gmail [dot] com> wrote:

Oh my...is there a workaround?

--
http://erikengbrecht.blogspot.com/

Overloading resolution is already complicated by:
- type inference of arguments;
- type inference of type arguments;
- named and default parameters;
- weak conformance;
- implicit views;
- implicit parameters;
- potential applicability of a methods to the arguments based on the
shape of the arguments;
- and finally, automatic tupling.

I tend to discourage use of overloading, instead favoring named and
default parameters and distinctly named methods. But when dealing with
third-party APIs, you can't just eschew overloading. Additional safety
measures, however small, would be beneficial here.

-jason

On Sun, Jul 11, 2010 at 11:51 PM, Erik Engbrecht
wrote:
> Oh, wait, I didn't look closely enough at the example.  I assume you
> specified the wrong number of arguments for the DateTime constructor in the
> second definition of time, so scalac happily tried to find a way to make it
> the right number of arguments.  So when one would expect a compile error due
> to the wrong number of arguments, one receives runtime error because scalac
> tuplized your arguments into a single object.
> Not pretty but not the end of the world.
>
> Man, my brain is slow today.

On Mon, Jul 12, 2010 at 12:08:25AM +0200, Jason Zaugg wrote:
> I tend to discourage use of overloading, instead favoring named and
> default parameters and distinctly named methods. But when dealing with
> third-party APIs, you can't just eschew overloading. Additional safety
> measures, however small, would be beneficial here.

Yeah, I'm no expert on the java landscape but if joda time has lots of
object-taking constructors then it's not uncommon enough.

This isn't exactly a separate bug (although I say it IS a bug that
BoxedUnit is not named "Tuple0") but another thing:

scala> def duration = new Duration
duration: org.joda.time.Duration

scala> duration
java.lang.IllegalArgumentException: No duration converter found for type: scala.runtime.BoxedUnit
at org.joda.time.convert.ConverterManager.getDurationConverter(ConverterManager.java:339)

Oh BoxedUnit, I never tire of your antics.

I can't wait to see that one on StackOverflow...
WTF is a BoxedUnit and how on earth did it get passed into my Duration constructor?
Well, sir, it's complicated...in the beginning there was the void, but the void did not fit well into the type system.  So the great Odersky said "let there be Unit!"  And the void collapsed in on itself and Unit emerged from the collapsing void.  But Unit, being begat of the void, had no substance, and therefore could not be passed into functions expecting an Any.  And so, to grant substance to the offspring of the void, the great Odersky said "hmm..well...I guess we have boxed everything else, so we'll box Unit."  And thus BoxedUnit was born.
Being of both substance and of the void, BoxUnit may spontaneously appear where no object exists yet the compiler deems an object is needed, leaving no trace but in the bytecode and suddenly emerging at runtime to surprise unwary programmers.
On Sun, Jul 11, 2010 at 6:19 PM, Paul Phillips <paulp [at] improving [dot] org> wrote:

On Mon, Jul 12, 2010 at 12:08:25AM +0200, Jason Zaugg wrote:
> I tend to discourage use of overloading, instead favoring named and
> default parameters and distinctly named methods. But when dealing with
> third-party APIs, you can't just eschew overloading. Additional safety
> measures, however small, would be beneficial here.

Yeah, I'm no expert on the java landscape but if joda time has lots of
object-taking constructors then it's not uncommon enough.

This isn't exactly a separate bug (although I say it IS a bug that
BoxedUnit is not named "Tuple0") but another thing:

scala> def duration = new Duration
duration: org.joda.time.Duration

scala> duration
java.lang.IllegalArgumentException: No duration converter found for type: scala.runtime.BoxedUnit
       at org.joda.time.convert.ConverterManager.getDurationConverter(ConverterManager.java:339)

Oh BoxedUnit, I never tire of your antics.

--
Paul Phillips      | Where there's smoke, there's mirrors!
Moral Alien        |
Empiricist         |
pp: i haul pills   |----------* http://www.improving.org/paulp/ *----------

--
http://erikengbrecht.blogspot.com/

> Date: Sun, 11 Jul 2010 14:25:41 -0700
> From: paulp [at] improving [dot] org

> I knew this risk existed but now having experienced it in this way I
> consider it past indecent. I think we must do something.

Stop using JODA?

Get a new e-mail account with Hotmail - Free. Sign-up now.

Hilarious, I love it! Have to go clean my keyboard now...

On 07/11/10 05:40 PM, Erik Engbrecht wrote:
> I can't wait to see that one on StackOverflow...
>
> WTF is a BoxedUnit and how on earth did it get passed into my Duration
> constructor?
>
> Well, sir, it's complicated...in the beginning there was the void, but the
> void did not fit well into the type system. So the great Odersky said "let
> there be Unit!" And the void collapsed in on itself and Unit emerged from
> the collapsing void. But Unit, being begat of the void, had no substance,
> and therefore could not be passed into functions expecting an Any. And so,
> to grant substance to the offspring of the void, the great Odersky said
> "hmm..well...I guess we have boxed everything else, so we'll box Unit." And
> thus BoxedUnit was born.
>
> Being of both substance and of the void, BoxUnit may spontaneously appear
> where no object exists yet the compiler deems an object is needed, leaving
> no trace but in the bytecode and suddenly emerging at runtime to surprise
> unwary programmers.