Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

traits should be able to call super on fields #1938

Open
scabug opened this issue Apr 30, 2009 · 13 comments
Open

traits should be able to call super on fields #1938

scabug opened this issue Apr 30, 2009 · 13 comments
Milestone

Comments

@scabug
Copy link

scabug commented Apr 30, 2009

As expressed by martin in #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.

@scabug
Copy link
Author

scabug commented Apr 30, 2009

Imported From: https://issues.scala-lang.org/browse/SI-1938?orig=1
Reporter: @paulp
See #1093

@scabug
Copy link
Author

scabug commented Jun 12, 2010

Antony Stubbs (astubbs) said:
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...

@scabug
Copy link
Author

scabug commented Jun 9, 2011

Tony Sloane (asloane) said:
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.

@scabug
Copy link
Author

scabug commented Oct 20, 2011

@paulbutcher said:
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.

@scabug
Copy link
Author

scabug commented Oct 27, 2011

Erik Bruchez (ebruchez) said:
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.

@scabug
Copy link
Author

scabug commented Nov 29, 2011

Ivan Fryda (ivanfoofoo) said (edited on Nov 29, 2011 10:48:03 PM UTC):
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)?

@scabug
Copy link
Author

scabug commented Apr 10, 2012

Tomer Gabel (holograph) said:
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.

@scabug
Copy link
Author

scabug commented Jul 1, 2012

@retronym said:
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

@scabug
Copy link
Author

scabug commented Jul 1, 2012

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

@scabug
Copy link
Author

scabug commented Jul 1, 2012

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

@scabug
Copy link
Author

scabug commented Apr 11, 2015

B. Tommy Jensen (tommy-at-grindvoll.com) said:
Another vote to fix this issue. I met this problem today; it would be extremely convenient to be able to access the content of a val in the base class.

@scabug scabug added this to the Backlog milestone Apr 6, 2017
@SethTisue
Copy link
Member

is this still an issue in 2.12?

@Jasper-M
Copy link
Member

I'm pretty sure it is.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants