variable cannot override a mutable variable

[Laxmikant Chitare]

Hi,

I can infer from google search this is a famous error. But could not find any link that could explain the reason. Here is my code:

class Base(var x:Int){

}

class Child(override var x:Int) extends Base(x)

In the declaration of Child class, I get an error "variable x cannot override a mutable variable". 

If I dont use override modifier, I get an error "variable x needs 'override' modifier".

How to get this working?

Thanks,

Laxmikant

[Oliver Ruebenacker]

     Hello,

  Don't make it a var, just make it a parameter (omit var keyword):

class Base(var x: Int) {

}

class Child(x: Int) extends Base(x)

     Best, Oliver

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Oliver Ruebenacker

Solutions Architect at Altisource Labs

Be always grateful, but never satisfied.

[Laxmikant Chitare]

Hi Oliver,

Thank you for a quick response. After implementing your suggestion and trying to modify x inside Child, I get this error:

"error: reassignment to val".

I am basically writing a test program where I want to derive child class from base class and be able to modify attributes of a base class. 

Thanks,

Laxmikant

[Oliver Ruebenacker]

     Hello,

  You can give the parameter a different name:

class Base(var x: Int) {

}

class Child(y: Int) extends Base(y) {

  x = 5

}

  I am actually surprised why this.x and super.x don't work (when the parameter has the same name x).

     Best, Oliver

[Roman Janusz]

Ugh.

This is terrible.

[Carlos Dañel Ferreyra]

I think there are like 6 synthetic class members generated every time you say "var". 

Perhaps that's where the clash happens.

[Som Snytt]

The spec needs a wiki-like blurb: "This explanatory section is a stub. You can help improve the spec..." etc and point to the contribution page.

http://www.scala-lang.org/files/archive/spec/2.11/06-expressions.html#this-and-super

For super.m,

The statically referenced member m must be a type or a method. <!-- explanation: so that we need not create several fields for overriding vals -->

There is a linter for the accidental shadowing:

scala> class X(var v: Int)
defined class X

scala> class Y(v: Int) extends X(v) { def f = 2 * v }
defined class Y

scala> :replay -Xlint
Replaying: class X(var v: Int)
defined class X

Replaying: class Y(v: Int) extends X(v) { def f = 2 * v }
<console>:8: warning: private[this] value v in class Y shadows mutable v inherited from class X.  Changes to v will not be visible within class Y - you may want to give them distinct names.
       class Y(v: Int) extends X(v) { def f = 2 * v }
                                                  ^
defined class Y

--

[Laxmikant Chitare]

Hi Oliver,

Having different name does not seem quite right. Parameter exists for a purpose and its name is the only thing that conveys the purpose. Is this so difficult in Scala? Isn't this a very obvious and general requirement?

Hi Carlos, I am new to Scala. I could not understand what you said about synthetic class.

Thanks,

Laxmikant

[Som Snytt]

A class parameter is one thing and a class member is another. It's usually convenient to use the simple syntax where they are the same thing, but this is an edge case.

Scala has two parents, a beautiful person with the initials F. P., and another rather warty sort with the initials O. O. P.

If you want to turn the param into a private field explicitly, you can

class C(x0: Int) extends X(x0) { private[this] val x = x0; def f = 2 * x }

obviously. Much virtual ink is spilled.

--

[Som Snytt]

I just happened to run across this, that I'd saved a few months ago:

Quote of the Day - Rene Magritte - "Everything we see hides another thing, we always want to see what is hidden by what we see."

I don't know if he meant shadowing.

[Carlos Ferreyra]

@Som like hiding vars behind pipes and green apples? :)

@Laxmikant Hi Laxmikant. What I meant by synthetic was the fact that the members are generated by the compiler and not the programmer. Also, I'd like to correct myself: When you declare a var, there are just 3 members generated, the property, the accesor and the mutator. If you annotate with @BeanProperty, you get two additional members, a getter and a setter.

  private int x;

  public int x() { return this.x; } 

  public void x_$eq(int x$1) { this.x = x$1; } 

  public void setX(int x$1) { this.x = x$1; } 

  public int getX() { return x(); }

You received this message because you are subscribed to a topic in the Google Groups "scala-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scala-user/M147e31HIyk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to scala-user+...@googlegroups.com.