trait T {
def x: Int = 42
}
class C extends T {
def x_=(n: Int) = ()
}
val c = new C
c.x = c.x + 10
c.x += 10
override def x = super.x
Hi Michel,
the implementation of setter and getter functions as an alternative to var needs be in the same class - see 4.2 Variable Declarations and Definitions of the Language Reference.
No more so than c.x = 42. The c.x + 10 is calculated and then the value assigned. It's the += sugar that the compiler can't figure out.
c.x = 42
c.x += foo
c.x = c.x + foo
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.
I understand the error; that's not the point. I'm looking for the "rule" you refer to, the reason why an interpretation is chosen when the accessor method is inherited but the other is taken when the accessor method is defined in the class. I though the absence of a += method would be enough to trigger the interpretation ... = ... + ..., but apparently that's not the case.
The re-interpretation occurs if the following two conditions are fulfilled.
+=
, and also cannot be converted by an implicit conversion to a value with a member named +=
.l = l + r
is type-correct. In particular this implies that l refers to a variable or object that can be assigned to, and that is convertible to a value with a member named +
.