This page is no longer maintained — Please continue to the home page at www.scala-lang.org

inconsistent behaviour for annotated constructor params

1 reply
Kevin Wright 2
Joined: 2010-05-30,
User offline. Last seen 26 weeks 4 days ago.
Using -Xprint
    class BippyTest(@proxy dg : Bippy) extends Bippy
will create the tree:
    class BippyTest extends java.lang.Object with autoproxy.test.Bippy with ScalaObject {       @autoproxy.annotation.proxy <paramaccessor> private[this] val dg: autoproxy.test.Bippy = _;       def this(@autoproxy.annotation.proxy dg: autoproxy.test.Bippy): autoproxy.test.BippyTest = {        BippyTest.super.this();        ()      }    }
whereas
    class BippyTest(@proxy val dg : Bippy) extends Bippy
will generate
    class BippyTest extends java.lang.Object with autoproxy.test.Bippy with ScalaObject {      <paramaccessor> private[this] val dg: autoproxy.test.Bippy = _;       <stable> <accessor> <paramaccessor> def dg: autoproxy.test.Bippy = BippyTest.this.dg;      def this(@autoproxy.annotation.proxy dg: autoproxy.test.Bippy): autoproxy.test.BippyTest = {         BippyTest.super.this();        ()      }    }
This understandably causes issues for annotation-driven plugins.  I had a look through trac and couldn't see this reported. Before I create a ticket, can I confirm that nobody is already aware of the issue.
--
Kevin Wright

gtalk / msn : kev.lee.wright@gmail.com kev.lee.wright@gmail.commail: kevin.wright@scalatechnology.com
vibe / skype: kev.lee.wrightquora: http://www.quora.com/Kevin-Wright
twitter: @thecoda

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra
rytz
Joined: 2008-07-01,
User offline. Last seen 45 weeks 5 days ago.
Re: inconsistent behaviour for annotated constructor params
Hi Kevin,

On Tue, Apr 5, 2011 at 23:47, Kevin Wright <kev.lee.wright@gmail.com> wrote:
Using -Xprint
    class BippyTest(@proxy dg : Bippy) extends Bippy
will create the tree:
    class BippyTest extends java.lang.Object with autoproxy.test.Bippy with ScalaObject {       @autoproxy.annotation.proxy <paramaccessor> private[this] val dg: autoproxy.test.Bippy = _;       def this(@autoproxy.annotation.proxy dg: autoproxy.test.Bippy): autoproxy.test.BippyTest = {        BippyTest.super.this();        ()      }    }


assuming that the annotation class (proxy) is itself not annotated with a target-meta-annotation,this is a bug. the annotation should end up only on the parameter by default.
 

whereas
    class BippyTest(@proxy val dg : Bippy) extends Bippy
will generate
    class BippyTest extends java.lang.Object with autoproxy.test.Bippy with ScalaObject {      <paramaccessor> private[this] val dg: autoproxy.test.Bippy = _;       <stable> <accessor> <paramaccessor> def dg: autoproxy.test.Bippy = BippyTest.this.dg;      def this(@autoproxy.annotation.proxy dg: autoproxy.test.Bippy): autoproxy.test.BippyTest = {         BippyTest.super.this();        ()      }    }


this is the correct behavior.
please report a bug.
 

This understandably causes issues for annotation-driven plugins.  I had a look through trac and couldn't see this reported. Before I create a ticket, can I confirm that nobody is already aware of the issue.
--
Kevin Wright

gtalk / msn : kev.lee.wright@gmail.com kev.lee.wright@gmail.commail: kevin.wright@scalatechnology.com
vibe / skype: kev.lee.wrightquora: http://www.quora.com/Kevin-Wright
twitter: @thecoda

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland