user504909
user504909

Reputation: 9559

scala inherited value do not find

Scala version 2.11.8

I have parent class

abstract class FR(externalId:String, code:String, message:String) extends Serializable {
val this.externalId=externalId;
val this.code = code;
val this.message = message;

def toString:String={
  return "FRworks";
}

}

The child class is:

class RD extends FR {
def this(lpTransaction:LPTransaction)={
externalId =lpTransaction.getField("somethinghere").toString
...
}
}

The error is:

Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0
[info] Loading project definition from F:\workspace\frankcheckAPI\project
[info] Set current project to frankcheckapi (in build file:/F:/workspace/frankcheckAPI/)
[info] Compiling 20 Scala sources to F:\workspace\frankcheckAPI\target\scala-2.11\classes...
[error] F:\workspace\frankcheckAPI\src\main\scala\com\cardaccess\fraudcheck\RD.scala:9: 'this' expected but identifier found.
[error]     externalId =lpTransaction.getField("somethinghere").toString
[error]     ^
[error] one error found
[error] (compile:compileIncremental) Compilation failed

when I add this in front of externalId the error still:

Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0
[info] Loading project definition from F:\workspace\frankcheckAPI\project
[info] Set current project to frankcheckapi (in build file:/F:/workspace/frankcheckAPI/)
[info] Compiling 20 Scala sources to F:\workspace\frankcheckAPI\target\scala-2.11\classes...
[error] F:\workspace\frankcheckAPI\src\main\scala\com\cardaccess\fraudcheck\ReDFraudCheckResponse.scala:9: '}' expected but '.' found.
[error]     this.externalId =lpTransaction.getField("somethinghere").toString
[error]         ^
[error] F:\workspace\frankcheckAPI\src\main\scala\com\cardaccess\fraudcheck\ReDFraudCheckResponse.scala:12: eof expected but '}' found.
[error] }
[error] ^
[error] two errors found
[error] (compile:compileIncremental) Compilation failed

Upvotes: 1

Views: 309

Answers (2)

Samar
Samar

Reputation: 2101

//scala automatically generates getters for passed in params. No need to set them explicitly. For immutable params use val, for mutable use var
abstract class FR(var externalId:String, val code:String, val message:String) extends Serializable {
//need to use override annotation for superclass methods
override def toString:String={
   return "FRworks";
 }
}
// notice how constructor parameters are passed to the base class when defining the child class.
class RD extends FR("someID","code","msg") {
  def printId() = println(externalId)  
}

val x = new RD
x.externalId = "new ID"  //works because externalId is var (mutable)
x.code = "new code"  //error because code is val (immutable) 

x.printId  //correctly prints the external id: someID

Upvotes: 0

slouc
slouc

Reputation: 9698

Your code is very Java-influenced. There are couple of things wrong here; when you fix the obvious ones like missing class parameters in RD it boils down to not being able to reassign to val.

Let me give you an improved, Scala-fied version of the whole code.

abstract class FR(val externalId: String, val code: String, val message: String) extends Serializable

// dummy class
class LPTransaction {
  def getField(s: String) = s
}

class RD(externalId: String, code: String, message: String) extends FR(externalId, code, message) {
  def this(lpTransaction: LPTransaction) = {
    this(lpTransaction.getField("somethinghere").toString, "defaultCode", "defaultMessage")
  }
  println(externalId)
}

val a = new RD(new LPTransaction) // prints "somethinghere"

Main improvements are:

  • You don't need private fields to be populated using arguments in the constructor. Scala favors immutability. Make your class arguments "vals", this means they will be available as public fields (instead of getters you will access them directly; this is contrary to OOP's encapsulation principle, but here it's ok because nobody can mess with them anyway since they are immutable; they may only be fetched)

  • Your subclass RD should be taking same fields as parameters as its parent class. Of course, you can then define an auxiliary constructor that takes only LPTransaction, but then you need to feed the parent class with some default values for the other parameters.

The rest kind of follows from this. I added the dummy implementation of LPTransaction to be able to compile. I also threw in a println statement in RD class just for the sake of example. Feel free to ask if something's not clear.

Upvotes: 1

Related Questions