Scala Programming Language
  1. Scala Programming Language
  2. SI-1938

traits should be able to call super on fields

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Misc Compiler
    • Labels:
      None

      Description

      As expressed by martin in SI-1093:

      the fix can and should be generalized so as to also allow super
      calls on trait fields. Should be relatively straightforward given
      the technique (rename trait val fields in addition to trait val
      setters).
      

      I'm closing that one and opening this one so it's not buried in a comment.

        Activity

        Hide
        Antony Stubbs added a comment -

        I have this problem with a java class in a 3rd party jar i am extending. My workaround was to implement a java class which extends the java class with the protected fields and implement a accessor method which has public access...

        Show
        Antony Stubbs added a comment - I have this problem with a java class in a 3rd party jar i am extending. My workaround was to implement a java class which extends the java class with the protected fields and implement a accessor method which has public access...
        Hide
        Tony Sloane added a comment -

        I'm wondering if I can stimulate some interest in addressing this "super on trait fields" feature in an upcoming release.

        It would be extremely useful when extending combinator parsers where a base language trait defines some parsers as vals (or lazy vals), then an extension language trait wants to override the parser to add some new constructs, but default back to the base language parser.

        There are some work-arounds where the vals are wrapped by defs, but the boilerplate gets in teh way of the cleanest expression of this kind of composition.

        Show
        Tony Sloane added a comment - I'm wondering if I can stimulate some interest in addressing this "super on trait fields" feature in an upcoming release. It would be extremely useful when extending combinator parsers where a base language trait defines some parsers as vals (or lazy vals), then an extension language trait wants to override the parser to add some new constructs, but default back to the base language parser. There are some work-arounds where the vals are wrapped by defs, but the boilerplate gets in teh way of the cleanest expression of this kind of composition.
        Hide
        Paul Butcher added a comment -

        I just ran into this, and while it's not a big issue, it's very "jarring" when you hit it. It means that you need to think very carefully about using a val in an interface if you expect it to be subclassed - which I haven't been worrying about up until now because I didn't know about this problem. Damn - I'm going to have to go back and look at lots of code I've written.

        Show
        Paul Butcher added a comment - I just ran into this, and while it's not a big issue, it's very "jarring" when you hit it. It means that you need to think very carefully about using a val in an interface if you expect it to be subclassed - which I haven't been worrying about up until now because I didn't know about this problem. Damn - I'm going to have to go back and look at lots of code I've written.
        Hide
        Erik Bruchez added a comment -

        I just ran into this as well. As Paul said, it is surprising when you hit it. Luckily a Google search quickly directs you to this page.

        Show
        Erik Bruchez added a comment - I just ran into this as well. As Paul said, it is surprising when you hit it. Luckily a Google search quickly directs you to this page.
        Hide
        Ivan Fryda added a comment - - edited

        I think I'm running into a similar issue. I'm trying to create a simple class:

        class Topping(var name:String)}}
        

        That class definition should create the implicit getter and setter for its name attribute. Then, I create a trait this way:

        trait LoggingNameTrait extends Topping {
        
          override def name_=(aName:String) {
            print(aName)
            super.name_=(aName) // this line doesn't compile
          }
        
        }
        

        The Scala compiler doesn't let me trait-overwrite the setter for the name attribute. Is this supposed to work this way (some kind of a language limitation)?

        Show
        Ivan Fryda added a comment - - edited I think I'm running into a similar issue. I'm trying to create a simple class: class Topping(var name:String)}} That class definition should create the implicit getter and setter for its name attribute. Then, I create a trait this way: trait LoggingNameTrait extends Topping { override def name_=(aName:String) { print(aName) super.name_=(aName) // this line doesn't compile } } The Scala compiler doesn't let me trait-overwrite the setter for the name attribute. Is this supposed to work this way (some kind of a language limitation)?
        Hide
        Tomer Gabel added a comment -

        Another vote, specifically around Ivan's use case. It should be trivial to override getter/setters in subclasses; there's "final" (or sealed, or whatever you want to call it) to prevent it if desirable, but it should not be a language limitation.

        Show
        Tomer Gabel added a comment - Another vote, specifically around Ivan's use case. It should be trivial to override getter/setters in subclasses; there's "final" (or sealed, or whatever you want to call it) to prevent it if desirable, but it should not be a language limitation.
        Hide
        Jason Zaugg added a comment -

        Looks like this is available under -Y.

         ~/code/scala ./build/quick/bin/scala -Yoverride-vars
        Welcome to Scala version 2.10.0-20120701-125412-ad51d82953 (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_31).
        Type in expressions to have them evaluated.
        Type :help for more information.
        
        scala> class Base { val a = 1; def b = 0 }; class Derived extends Base { override val a = super.a + 1 }
        defined class Base
        defined class Derived
        
        scala> new Derived().a
        res0: Int = 2
        
        scala> trait Base { val a = 1; def b = 0 }; class Derived extends Base { override val a = super.a + 1 }
        defined trait Base
        defined class Derived
        
        scala> new Derived().a
        res1: Int = 1
        
        Show
        Jason Zaugg added a comment - Looks like this is available under -Y. ~/code/scala ./build/quick/bin/scala -Yoverride-vars Welcome to Scala version 2.10.0-20120701-125412-ad51d82953 (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_31). Type in expressions to have them evaluated. Type :help for more information. scala> class Base { val a = 1; def b = 0 }; class Derived extends Base { override val a = super.a + 1 } defined class Base defined class Derived scala> new Derived().a res0: Int = 2 scala> trait Base { val a = 1; def b = 0 }; class Derived extends Base { override val a = super.a + 1 } defined trait Base defined class Derived scala> new Derived().a res1: Int = 1
        Hide
        Paul Phillips added a comment -

        It's full of holes though. Truly experimental, not "experimental as a nod to the possibility of bugs."

        Show
        Paul Phillips added a comment - It's full of holes though. Truly experimental, not "experimental as a nod to the possibility of bugs."
        Hide
        Jason Zaugg added a comment -

        Oh right, holes like the one I stepped into in my second example without noticing. Too bad.

        Show
        Jason Zaugg added a comment - Oh right, holes like the one I stepped into in my second example without noticing. Too bad.

          People

          • Assignee:
            Martin Odersky
            Reporter:
            Paul Phillips
            TracCC:
            Antony Stubbs, Mike, Mikhail Vorozhtsov, Nils, Seth Tisue
          • Votes:
            16 Vote for this issue
            Watchers:
            19 Start watching this issue

            Dates

            • Created:
              Updated:

              Development