The encoding of default arguments

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: The encoding of default arguments

Jason Zaugg
Defaults are virtual methods, and parameter names in overriding methods might differ.
On Sat., 12 Nov. 2016 at 09:50, Dale Wijnand <[hidden email]> 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 [hidden email].
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: The encoding of default arguments

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


On Sat, 12 Nov 2016, 00:01 Jason Zaugg, <[hidden email]> wrote:
Defaults are virtual methods, and parameter names in overriding methods might differ.
On Sat., 12 Nov. 2016 at 09:50, Dale Wijnand <[hidden email]> 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 [hidden email].
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 [hidden email].
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: The encoding of default arguments

Lukas Rytz-2


On Sat, Nov 12, 2016 at 10:26 AM, Dale Wijnand <[hidden email]> 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, <[hidden email]> wrote:
Defaults are virtual methods, and parameter names in overriding methods might differ.
On Sat., 12 Nov. 2016 at 09:50, Dale Wijnand <[hidden email]> 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 [hidden email].
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 [hidden email].
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 [hidden email].
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.