Encoding of named and default arguments?

On Fri, May 1, 2009 at 11:04, David MacIver <david.maciver@gmail.com> wrote:

Hi,

So, I wrote this thing:

http://github.com/DRMacIver/optional/

It's a command line parser for Scala which uses reflection on method
names to figure out options to use. It works pretty well!

There are two warts:

a) It uses paranamer to figure out parameter names. this isn't the end
of the world, but it would be nice to do it without.
b) The encoding of default arguments is ugly as sin and hard to make typesafe.

So I'm wondering if in 2.8 it will be possible to grab hold of the
generation of default arguments reflectively. I don't require any sort
of explicit support for this, just that the encoding is exposed in
some relatively convenient way for doing so. Hence my curiousity: How
are default arguments made available in the bytecode? Is there some
encoding in terms of methods with a consistent naming convention?

For every parameter of "foo" which has a default there will be a method called

  foo$default$n

where n is the position of the argument (starting with 1). (Note that if "foo" is
overloaded, only one alternative is allowed to have defaults, so there are no
name clashes.) Example>

  class A { def foo(x: Int = 0, y: String) = 0 }

==> after typer:

        class A extends java.lang.Object with ScalaObject {
          def this(): $iw.$iw.A = {
            A.super.this();
            ()
          };
          def foo(x: Int = 0, y: String): Int = 0;
          <synthetic> def foo$default$1: Int = 0
        }



The defaults take the same type parameters as the original method, and
all preceding value parameter lists. e.g. "foo[T](a: Int)(b: Int = a)" gives

  <synthetic> def foo$default$2[T](a: Int): Int = a


Cheers: Lukas

2009/5/1 Lukas Rytz :
>
>
> On Fri, May 1, 2009 at 11:04, David MacIver wrote:
>>
>> Hi,
>>
>> So, I wrote this thing:
>>
>> http://github.com/DRMacIver/optional/
>>
>> It's a command line parser for Scala which uses reflection on method
>> names to figure out options to use. It works pretty well!
>>
>> There are two warts:
>>
>> a) It uses paranamer to figure out parameter names. this isn't the end
>> of the world, but it would be nice to do it without.
>> b) The encoding of default arguments is ugly as sin and hard to make
>> typesafe.
>>
>> So I'm wondering if in 2.8 it will be possible to grab hold of the
>> generation of default arguments reflectively. I don't require any sort
>> of explicit support for this, just that the encoding is exposed in
>> some relatively convenient way for doing so. Hence my curiousity: How
>> are default arguments made available in the bytecode? Is there some
>> encoding in terms of methods with a consistent naming convention?
>
> For every parameter of "foo" which has a default there will be a method
> called
>
>   foo$default$n
>
> where n is the position of the argument (starting with 1). (Note that if
> "foo" is
> overloaded, only one alternative is allowed to have defaults, so there are
> no
> name clashes.) Example>
>
>   class A { def foo(x: Int = 0, y: String) = 0 }
>
> ==> after typer:
>
>         class A extends java.lang.Object with ScalaObject {
>           def this(): $iw.$iw.A = {
>             A.super.this();
>             ()
>           };
>           def foo(x: Int = 0, y: String): Int = 0;
>           def foo$default$1: Int = 0
>         }
>
>
>
> The defaults take the same type parameters as the original method, and
> all preceding value parameter lists. e.g. "foo[T](a: Int)(b: Int = a)" gives
>
>   def foo$default$2[T](a: Int): Int = a
>
>
> Cheers: Lukas
>

Marvelous! This is picture perfect the exact encoding I was hoping for. :-)

Bah. If anyone wanted to play around with this, I have to apologise:
I've just noticed I failed to commit the crucial class that ties
everything together! It's at home, so I'll have to commit it later.