Let us assume we have the two following classes:
abstract case class MyParent(param: Int) {
// ...
}
case class MyChild(param: Int) extends MyParent(param: Int) {
// ... ^^^^^ ^^^^^
}
Making them both case classes resulted in an error in both param usage places, which says that it needs the override modifier that will override the value from the parent class. This looks strange to me.. why do I have to invent other param names here.. why is this order of things enforced? Where is the profit?
You never should derive a case class from another case class!
Try this in a REPL started with scala -deprecation:
scala> case class Foo(foo: String)
defined class Foo
scala> case class Bar(override val foo: String) extends Foo(foo)
<console>:9: warning: case class `class Bar' has case ancestor `class Foo'. Case-to-case inheritance has potentially dangerous bugs which are unlikely to be fixed. You are strongly encouraged to instead use extractors to pattern match on non-leaf nodes.
A quick fix for that is to do this
abstract case class MyParent(param: Int) {
println("Form parent : " + param)
}
case class MyChild(override val param: Int) extends MyParent(param) {
println("Form child : " + param)
}
val c = MyChild(10);
This will result in this
>> From parent : 10
>> From child : 10
Actually the extends MyParent() is not like in Java. This is a way to tell MyChild extends MyParent, and call the super constructor of the latter at first.
Where is the profit?
Simply the lack of a not-too-useful special case. param in case class MyChild(param: Int) is a class member as well as a constructor parameter, so one of ancestors already has a (non-abstract) param member, it has to be overridden. And Scala requires override keyword when overriding everywhere else, so it requires it here as well.
As far as my limited Scala knowledge goes, case classes are typically used for immutable algebraic data types and pattern matching. Therefore, instead of creating a "child class", you should probably instead create a class which contains the "parent" class.
> case class MyParent(param: Int)
defined class MyParent
> case class MyChild(param: Int, parent: MyParent)
defined class MyChild
> def foo(c: MyChild) = c match {
case MyChild(p, MyParent(p2)) => println("p: " + p + ", p2 " + p2)
}
foo: (c: MyChild)Unit
> foo(MyChild(3, MyParent(4)))
p: 3, p2 4
Related
Scala throws "reassignment to val" error for the following code.
abstract case class Gun(var bulletCount:Int)
class Pistol(bulletCount:Int) extends Gun(bulletCount){
def fire() { bulletCount=bulletCount-1 }
}
Anything I missed here?
For starters, you should consider case class as final, and not extend them.
Second, do not use var with case class, you should rather create a copy of a case class to get one of its field changed.
Third, if you want a common type, you can use a base trait.
All in one, here's what it could look like:
sealed trait Gun {
def bulletCount: Int
}
case class Pistol(bulletCount: Int) extends Gun {
def fire(): Pistol = copy(bulletCount=bulletCount)
}
You're referring to bulletCount field generated by Pistol primary constructor parameter. To set base class variable, you need to directly call field using super:
class Pistol(bulletCount: Int) extends Gun(bulletCount) {
def fire(): Unit = {
super.bulletCount = super.bulletCount - 1
}
}
Alternatively, you can label parameter-generated field with override var:
class Pistol(override var bulletCount: Int) extends Gun(bulletCount) {
def fire(): Unit = {
bulletCount = bulletCount - 1
}
}
On a side note, as Frederic A. suggested in his answer, you should avoid inheriting case classes. They are syntactic sugar, and code generation don't work over inheritance - you'll need to implement all the fancy stuff like apply or unapply methods in companion class all by yourself. Scala compiler team tried to support case class to case class inheritance, but discovered that it breaks structural equality and lots of other things.
I have a Base class have some function and val, I want to inherent them in my inherent case class how to do it ?
This is my base class:
class Base(val name:String, val number:int) extends Sometrait {
def copy(name:String=this.name, number:int=this.number){
new Base(name, number)
}
}
I want to write the:
case class SomeCase(val name:String, val number:int, val id:int)extends Base(String, number){
...
}
But the compiler always told me:
value **** needs `override' modifier social.scala /scalatest/src/scalatest line 35 Scala
But I really want to is just do as inherent not override, how to do it.
(I need to put the child class as case class, as it is easy for me to use in slick. (here is my another question for how to use class as table content class in slick, someone give me really great answer, but I still mass.))
Because name and number fields in both Base and SomeCase are defined with val without any modifiers like private, they are both public members and participate in inheritance. Because these fields have same names in base and child classes, you have to add override modifier before val name and val number in the child class:
case class SomeCase(override val name: String,
override val number: Int,
val id: Int) extends Base(name, number) { ... }
I want to do something like this:
sealed abstract class Base(val myparam:String)
case class Foo(override val myparam:String) extends Base(myparam)
case class Bar(override val myparam:String) extends Base(myparam)
def getIt( a:Base ) = a.copy(myparam="changed")
I can't, because in the context of getIt, I haven't told the compiler that every Base has a 'copy' method, but copy isn't really a method either so I don't think there's a trait or abstract method I can put in Base to make this work properly. Or, is there?
If I try to define Base as abstract class Base{ def copy(myparam:String):Base }, then case class Foo(myparam:String) extends Base results in class Foo needs to be abstract, since method copy in class Base of type (myparam: String)Base is not defined
Is there some other way to tell the compiler that all Base classes will be case classes in their implementation? Some trait that means "has the properties of a case class"?
I could make Base be a case class, but then I get compiler warnings saying that inheritance from case classes is deprecated?
I know I can also:
def getIt(f:Base)={
(f.getClass.getConstructors.head).newInstance("yeah").asInstanceOf[Base]
}
but... that seems very ugly.
Thoughts? Is my whole approach just "wrong" ?
UPDATE I changed the base class to contain the attribute, and made the case classes use the "override" keyword. This better reflects the actual problem and makes the problem more realistic in consideration of Edmondo1984's response.
This is old answer, before the question was changed.
Strongly typed programming languages prevent what you are trying to do. Let's see why.
The idea of a method with the following signature:
def getIt( a:Base ) : Unit
Is that the body of the method will be able to access a properties visible through Base class or interface, i.e. the properties and methods defined only on the Base class/interface or its parents. During code execution, each specific instance passed to the getIt method might have a different subclass but the compile type of a will always be Base
One can reason in this way:
Ok I have a class Base, I inherit it in two case classes and I add a
property with the same name, and then I try to access the property on
the instance of Base.
A simple example shows why this is unsafe:
sealed abstract class Base
case class Foo(myparam:String) extends Base
case class Bar(myparam:String) extends Base
case class Evil(myEvilParam:String) extends Base
def getIt( a:Base ) = a.copy(myparam="changed")
In the following case, if the compiler didn't throw an error at compile time, it means the code would try to access a property that does not exist at runtime. This is not possible in strictly typed programming languages: you have traded restrictions on the code you can write for a much stronger verification of your code by the compiler, knowing that this reduces dramatically the number of bugs your code can contain
This is the new answer. It is a little long because few points are needed before getting to the conclusion
Unluckily, you can't rely on the mechanism of case classes copy to implement what you propose. The way the copy method works is simply a copy constructor which you can implement yourself in a non-case class. Let's create a case class and disassemble it in the REPL:
scala> case class MyClass(name:String, surname:String, myJob:String)
defined class MyClass
scala> :javap MyClass
Compiled from "<console>"
public class MyClass extends java.lang.Object implements scala.ScalaObject,scala.Product,scala.Serializable{
public scala.collection.Iterator productIterator();
public scala.collection.Iterator productElements();
public java.lang.String name();
public java.lang.String surname();
public java.lang.String myJob();
public MyClass copy(java.lang.String, java.lang.String, java.lang.String);
public java.lang.String copy$default$3();
public java.lang.String copy$default$2();
public java.lang.String copy$default$1();
public int hashCode();
public java.lang.String toString();
public boolean equals(java.lang.Object);
public java.lang.String productPrefix();
public int productArity();
public java.lang.Object productElement(int);
public boolean canEqual(java.lang.Object);
public MyClass(java.lang.String, java.lang.String, java.lang.String);
}
In Scala, the copy method takes three parameter and can eventually use the one from the current instance for the one you haven't specified ( the Scala language provides among its features default values for parameters in method calls)
Let's go down in our analysis and take again the code as updated:
sealed abstract class Base(val myparam:String)
case class Foo(override val myparam:String) extends Base(myparam)
case class Bar(override val myparam:String) extends Base(myparam)
def getIt( a:Base ) = a.copy(myparam="changed")
Now in order to make this compile, we would need to use in the signature of getIt(a:MyType) a MyType that respect the following contract:
Anything that has a parameter myparam and maybe other parameters which
have default value
All these methods would be suitable:
def copy(myParam:String) = null
def copy(myParam:String, myParam2:String="hello") = null
def copy(myParam:String,myParam2:Option[Option[Option[Double]]]=None) = null
There is no way to express this contract in Scala, however there are advanced techniques that can be helpful.
The first observation that we can do is that there is a strict relation between case classes and tuples in Scala. In fact case classes are somehow tuples with additional behaviour and named properties.
The second observation is that, since the number of properties of your classes hierarchy is not guaranteed to be the same, the copy method signature is not guaranteed to be the same.
In practice, supposing AnyTuple[Int] describes any Tuple of any size where the first value is of type Int, we are looking to do something like that:
def copyTupleChangingFirstElement(myParam:AnyTuple[Int], newValue:Int) = myParam.copy(_1=newValue)
This would not be to difficult if all the elements were Int. A tuple with all element of the same type is a List, and we know how to replace the first element of a List. We would need to convert any TupleX to List, replace the first element, and convert the List back to TupleX. Yes we will need to write all the converters for all the values that X might assume. Annoying but not difficult.
In our case though, not all the elements are Int. We want to treat Tuple where the elements are of different type as if they were all the same if the first element is an Int. This is called
"Abstracting over arity"
i.e. treating tuples of different size in a generic way, independently of their size. To do it, we need to convert them into a special list which supports heterogenous types, named HList
Conclusion
Case classes inheritance is deprecated for very good reason, as you can find out from multiple posts in the mailing list: http://www.scala-lang.org/node/3289
You have two strategies to deal with your problem:
If you have a limited number of fields you require to change, use an approach such as the one suggested by #Ron, which is having a copy method. If you want to do it without losing type information, I would go for generifying the base class
sealed abstract class Base[T](val param:String){
def copy(param:String):T
}
class Foo(param:String) extends Base[Foo](param){
def copy(param: String) = new Foo(param)
}
def getIt[T](a:Base[T]) : T = a.copy("hello")
scala> new Foo("Pippo")
res0: Foo = Foo#4ab8fba5
scala> getIt(res0)
res1: Foo = Foo#5b927504
scala> res1.param
res2: String = hello
If you really want to abstract over arity, a solution is to use a library developed by Miles Sabin called Shapeless. There is a question here which has been asked after a discussion : Are HLists nothing more than a convoluted way of writing tuples? but I tell you this is going to give you some headache
If the two case classes would diverge over time so that they have different fields, then the shared copy approach would cease to work.
It is better to define an abstract def withMyParam(newParam: X): Base. Even better, you can introduce an abstract type to retain the case class type upon return:
scala> trait T {
| type Sub <: T
| def myParam: String
| def withMyParam(newParam: String): Sub
| }
defined trait T
scala> case class Foo(myParam: String) extends T {
| type Sub = Foo
| override def withMyParam(newParam: String) = this.copy(myParam = newParam)
| }
defined class Foo
scala>
scala> case class Bar(myParam: String) extends T {
| type Sub = Bar
| override def withMyParam(newParam: String) = this.copy(myParam = newParam)
| }
defined class Bar
scala> Bar("hello").withMyParam("dolly")
res0: Bar = Bar(dolly)
TL;DR: I managed to declare the copy method on Base while still letting the compiler auto generate its implementations in the derived case classes. This involves a little trick (and actually I'd myself just redesign the type hierarchy) but at least it goes to show that you can indeed make it work without writing boiler plate code in any of the derived case classes.
First, and as already mentioned by ron and Edmondo1984, you'll get into troubles if your case classes have different fields.
I'll strictly stick to your example though, and assume that all your case classes have the same fields (looking at your github link, this seems to be the case of your actual code too).
Given that all your case classes have the same fields, the auto-generated copy methods will have the same signature which is a good start. It seems reasonable then to just add the common definition in Base, as you did:
abstract class Base{ def copy(myparam: String):Base }
The problem is now that scala won't generate the copy methods, because there is already one in the base class.
It turns out that there is another way to statically ensure that Base has the right copy method, and it is through structural typing and self-type annotation:
type Copyable = { def copy(myParam: String): Base }
sealed abstract class Base(val myParam: String) { this : Copyable => }
And unlike in our earlier attempt, this will not prevent scala to auto-generate the copy methods.
There is one last problem: the self-type annotation makes sure that sub-classes of Base have a copy method, but it does not make it publicly availabe on Base:
val foo: Base = Foo("hello")
foo.copy()
scala> error: value copy is not a member of Base
To work around this we can add an implicit conversion from Base to Copyable. A simple cast will do, as a Base is guaranteed to be a Copyable:
implicit def toCopyable( base: Base ): Base with Copyable = base.asInstanceOf[Base with Copyable]
Wrapping up, this gives us:
object Base {
type Copyable = { def copy(myParam: String): Base }
implicit def toCopyable( base: Base ): Base with Copyable = base.asInstanceOf[Base with Copyable]
}
sealed abstract class Base(val myParam: String) { this : Base. Copyable => }
case class Foo(override val myParam: String) extends Base( myParam )
case class Bar(override val myParam: String) extends Base( myParam )
def getIt( a:Base ) = a.copy(myParam="changed")
Bonus effect: if we try to define a case class with a different signature, we get a compile error:
case class Baz(override val myParam: String, truc: Int) extends Base( myParam )
scala> error: illegal inheritance; self-type Baz does not conform to Base's selftype Base with Base.Copyable
To finish, one warning: you should probably just revise your design to avoid having to resort to the above trick.
In your case, ron's suggestion to use a single case class with an additional etype field seems more than reasonable.
I think this is what extension methods are for. Take your pick of implementation strategies for the copy method itself.
I like here that the problem is solved in one place.
It's interesting to ask why there is no trait for caseness: it wouldn't say much about how to invoke copy, except that it can always be invoked without args, copy().
sealed trait Base { def p1: String }
case class Foo(val p1: String) extends Base
case class Bar(val p1: String, p2: String) extends Base
case class Rab(val p2: String, p1: String) extends Base
case class Baz(val p1: String)(val p3: String = p1.reverse) extends Base
object CopyCase extends App {
implicit class Copy(val b: Base) extends AnyVal {
def copy(p1: String): Base = b match {
case foo: Foo => foo.copy(p1 = p1)
case bar: Bar => bar.copy(p1 = p1)
case rab: Rab => rab.copy(p1 = p1)
case baz: Baz => baz.copy(p1 = p1)(p1.reverse)
}
//def copy(p1: String): Base = reflect invoke
//def copy(p1: String): Base = macro xcopy
}
val f = Foo("param1")
val g = f.copy(p1="param2") // normal
val h: Base = Bar("A", "B")
val j = h.copy("basic") // enhanced
println(List(f,g,h,j) mkString ", ")
val bs = List(Foo("param1"), Bar("A","B"), Rab("A","B"), Baz("param3")())
val vs = bs map (b => b copy (p1 = b.p1 * 2))
println(vs)
}
Just for fun, reflective copy:
// finger exercise in the api
def copy(p1: String): Base = {
import scala.reflect.runtime.{ currentMirror => cm }
import scala.reflect.runtime.universe._
val im = cm.reflect(b)
val ts = im.symbol.typeSignature
val copySym = ts.member(newTermName("copy")).asMethod
def element(p: Symbol): Any = (im reflectMethod ts.member(p.name).asMethod)()
val args = for (ps <- copySym.params; p <- ps) yield {
if (p.name.toString == "p1") p1 else element(p)
}
(im reflectMethod copySym)(args: _*).asInstanceOf[Base]
}
This works fine for me:
sealed abstract class Base { def copy(myparam: String): Base }
case class Foo(myparam:String) extends Base {
override def copy(x: String = myparam) = Foo(x)
}
def copyBase(x: Base) = x.copy("changed")
copyBase(Foo("abc")) //Foo(changed)
There is a very comprehensive explanation of how to do this using shapeless at http://www.cakesolutions.net/teamblogs/copying-sealed-trait-instances-a-journey-through-generic-programming-and-shapeless ; in case the link breaks, the approach uses the copySyntax utilities from shapeless, which should be sufficient to find more details.
Its an old problem, with an old solution,
https://code.google.com/p/scala-scales/wiki/VirtualConstructorPreSIP
made before the case class copy method existed.
So in reference to this problem each case class MUST be a leaf node anyway, so define the copy and a MyType / thisType plus the newThis function and you are set, each case class fixes the type. If you want to widen the tree/newThis function and use default parameters you'll have to change the name.
as an aside - I've been waiting for compiler plugin magic to improve before implementing this but type macros may be the magic juice. Search in the lists for Kevin's AutoProxy for a more detailed explanation of why my code never went anywhere
case class Message(xml : Node) {
def toXML : Node = xml
}
case class ReqValidationMessage (xml : Node) extends Message(xml){
// ...
}
This causes a property naming conflict as Scala tries to create a second property named xml in ReqValidationMessage case class. But I want both constructors (of Message and ReqValidationMessage) to have the same argumentation. What should I do?
The short answer is: You should not extend a case class — case class inheritance is now deprecated.
Instead of subclassing case classes, why not use mixins to replicate common features:
trait XMLConvertible {
def xml: Node
def toXML = xml
}
case class Message(xml : Node) extends XMLConvertible
case class ReqValidationMessage(xml : Node) extends XMLConvertible {
//...
}
Then if you want to use directly XMLConvertible for pattern matching add a companion object:
object XMLConvertible {
def unapply( xc: XMLConvertible ) = Some( xc.xml )
}
Which allows you to write:
case XMLConvertible(xml) => println( xml )
If you want to stick with the scheme you presented, then you can just change the name of argument in second constructor - to something like xml2. Then you will have no naming conflict, and everything will work.
I have an abstract base class with several optional parameters:
abstract case class Hypothesis(
requirement: Boolean = false,
onlyDays: Seq[Int] = Nil,
…
) extends Something {…}
Do i really need to explicitly repeat all parameters with the additional keywords override val on top‽
case class SomeHypothesis(
anotherArg: SomeType,
override val requirement: Boolean = false,
override val onlyDays: Seq[Int] = Nil,
…
) extends Hypothesis(
requirement,
onlyDays,
…
) {…}
Or is there a syntax like
case class SomeHypothesis(anotherArg: SomeType, **) extends Hypothesis(**) {…}
I don’t even need anotherArg, just a way to pass all keyword args to the super constructor.
I really like Scala’s idea about constructors, but if there isn’t a syntax for that one, I’ll be disappoint :(
You can just use a dummy name in the inherited class:
case class SomeHypothesis(anotherArg: SomeType, rq: Boolean = false, odays: Seq[Int] = Nil)
extends Hypothesis(rq, odays)
but you do have to repeat the default values. There is no need to override a val.
EDIT:
Note that your abstract class should not be a case class. Extending case classes is now deprecated. You should use an extractor for you abstract class instead:
abstract class SomeHypothesis(val request: Boolean)
object SomeHypothesis {
def unapply(o: Any): Option[Boolean] = o match {
case sh: SomeHypothesis => Some(sh.request)
case _ => None
}
}
In my mind the policy of default values doesn't belong in the base class but should go on the concrete classes. I'd instead do the following:
trait Hypothesis {
def requirement: Boolean
def onlyDays: Seq[Int]
/* other common attributes as necessary */
}
case class SomeHypothesis(anotherArg: SomeType,
requirement: Boolean = false,
onlyDays: Seq[Int] = Nil)
extends Hypothesis
The case class fields of SomeHypothesis will fulfill the requirements of the Hypothesis trait.
As others have said, you can still use an extractor for pattern matching on the common parts:
object Hypothesis {
def unapply(h: Hypothesis): (Boolean, Seq[Int]) = (h.requirement, h.onlyDays)
}
I've spend DAYS bashing my head on the desk trying to understand why named params were not going into an extended class.
I tried traits, copy() you name it - me and the compiler were always at odds and when things did compile the values never got passed.
So to be clear if you have class
class A(someInt:Int = 0, someString: String ="xyz", someOtherString: String = "zyx")
And you want to extend it:
class B extends A // does NOT compile
class B(someInt: Int, someString: String, someOtherString: String) extends A // compiles but does not work as expected
You would think that a call to B like so:
case object X = B(someInt=4, someString="Boo", someOtherString="Who")
Would in fact either NOT compile (sadly it does) or actually work (it does NOT)
Instead you need to create B as follows (yes this is a repeat of an above answer but it wasn't obvious at first when google led me here...)
class B(someInt: Int, someString: String, someOtherString: String) extends A(someInt, someString, someOtherString)
and now
case object X = B(someInt=4, someString="Boo", someOtherString="Who")
Both COMPILES and WORKS
I have not yet worked out all the combinations and permutations of what/when and where you can put default values in the class B constructor but I'm pretty sure that defaults can be specified in the definition of class B with "expected" results.
If Hypothesis is an abstract class, then I'd not have a constructor for it. I'd
set those parameters as abstract attributes of the abstract class.
But then, in this case you do need the override modifier.