--
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.
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
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, <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.