The encoding of default arguments

[Dale Wijnand]

Does anyone know, is there's any particular reason why the encoding of default arguments as (eg.) "copy$default$1" and "copy$default$2", rather than "copy$default$x" and "copy$default$y" (given parameter names "x" and "y")?

Thanks,

Dale

[Jason Zaugg]

Defaults are virtual methods, and parameter names in overriding methods might differ.

--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dale Wijnand]

But don't you have to redefine any default argument you want to provide in your overriding method?

I might be missing the obvious, but could you show me with an example why an index-based encoding is the better encoding?

I'm looking at this to see if I can utilise default arguments in growable, backwards compatible datatypes (for sbt 1.0), and their parameter names are already significant for source compatibility (thus the existence of @deprecatedName) but the fact that it's encoded by index makes it binary incompatible (see https://github.com/sbt/sbt-datatype/issues/48).

Thanks

[Lukas Rytz]

On Sat, Nov 12, 2016 at 10:26 AM, Dale Wijnand <dale.w...@gmail.com> wrote:

But don't you have to redefine any default argument you want to provide in your overriding method?

You don't have to, but you can..

scala> class C { def f(x: Int = 1) = x }

scala> class D extends C { override def f(y: Int = 2) = y }

scala> (new D(): C).f()

res2: Int = 2

I might be missing the obvious, but could you show me with an example why an index-based encoding is the better encoding?

I'm looking at this to see if I can utilise default arguments in growable, backwards compatible datatypes (for sbt 1.0), and their parameter names are already significant for source compatibility (thus the existence of @deprecatedName) but the fact that it's encoded by index makes it binary incompatible (see https://github.com/sbt/sbt-datatype/issues/48).

Thanks

On Sat, 12 Nov 2016, 00:01 Jason Zaugg, <jza...@gmail.com> wrote:

Defaults are virtual methods, and parameter names in overriding methods might differ.

On Sat., 12 Nov. 2016 at 09:50, Dale Wijnand <dale.w...@gmail.com> wrote:

Does anyone know, is there's any particular reason why the encoding of default arguments as (eg.) "copy$default$1" and "copy$default$2", rather than "copy$default$x" and "copy$default$y" (given parameter names "x" and "y")?

Thanks,

Dale

--
You received this message because you are subscribed to the Google Groups "scala-internals" group.

To unsubscribe from this group and stop receiving emails from it, send an email to scala-internals+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-internals" group.

To unsubscribe from this group and stop receiving emails from it, send an email to scala-internals+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-internals" group.

To unsubscribe from this group and stop receiving emails from it, send an email to scala-internals+unsubscribe@googlegroups.com.