1

I have a piece of code that looks like the following

abstract class ClassA(var data: String) {
}

case class ClassB (data:String) extends ClassA(data){
}

This throws me an error saying, parameter data needs override modifier. I wouldn't get this error if the ClassB was a regular class instead of a case class.

In order to make it compile while keeping the case class, I have to change the name of the mutable variable when I'm extending base class.

case class ClassB (data2:String) extends ClassA(data2){
}

Why is this the case and is there a more elegant way of handling this?

zero323
  • 322,348
  • 103
  • 959
  • 935
rasthiya
  • 650
  • 1
  • 6
  • 20
  • 2
    "I wouldn't get this error if the ClassB was a regular class instead of a case class" - I tried with a normal class and it throws the same errors. According to the answers to [this question](https://stackoverflow.com/questions/16413986/how-to-override-a-mutable-variable-in-trait-in-scala) you cannot override a mutable variable _(which kinda makes sense, since you can just assign it another value)_. Additionally, **case classes** are for modeling _IMMUTABLE_ data structures. Thus, I don't think it is a good idea to mix them with anything mutable. Any reason why you want to do that? – Luis Miguel Mejía Suárez Jan 29 '19 at 20:01
  • No particular reason. I'm working on a half done library and some classes were defined as case classes. I guess having mutable variables defeats the purpose of having a case class in the first place and I should replace them with regular classes – rasthiya Jan 29 '19 at 20:09
  • "I tried with a normal class and it throws the same errors" - Surprisingly it's not the same case for me. If I define ClassB like "class ClassB (data:String) extends ClassA(data){ }" I don't get an error. – rasthiya Jan 29 '19 at 20:14
  • Or stick to an immutable programming style. The same way mutable variables defeats the purpose of having a case class, having well defined ADTs and powerful abstractions defeats the purpose of having mutable variables. But, well, those are only opinions and _personal tastes_. - `class ClassB (data:String) extends ClassA(data)` here you are not really overriding `data`, just assigning it a value. – Luis Miguel Mejía Suárez Jan 29 '19 at 20:17
  • 1
    Expanding my previous comment, what is happening there is that the first data is a immutable val only visible to the class itself, which has to be passed as and argument when constructing the class - then, this val is passed as the argument of the constructor of `ClassA`, which is a mutable a public variable. What happens is that from an external point of view you are using the `data` defined in `ClassA`. - You can check that whit this `class ClassB (data:String) extends ClassA (data) { def getData: String = this.data }` create an instance of `ClassB` and update `data`, then call `getData` ;) – Luis Miguel Mejía Suárez Jan 29 '19 at 20:22
  • 1
    getData still returns the same value with which the object was initialized. Your explanation makes so much sense with the example. Thank you. – rasthiya Jan 29 '19 at 20:40

0 Answers0