Getters and setters

85 views
Skip to first unread message

Michel Charpentier

unread,
Oct 21, 2016, 8:53:08 AM10/21/16
to scala-user
Consider this code:

trait T {
 
def x: Int = 42
}
class C extends T {
 
def x_=(n: Int) = ()
}

val c
= new C

I can then write this:

c.x = c.x + 10

but not this:

c.x += 10

I can, however, write the += form if I add an x method to class C:

override def x = super.x

Is there any logic behind this?  I can't figure it out.

MC

Sonnenschein

unread,
Oct 22, 2016, 5:48:47 AM10/22/16
to scala-user
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.

Peter

Michel Charpentier

unread,
Oct 22, 2016, 9:43:29 AM10/22/16
to scala-user


On Saturday, October 22, 2016 at 5:48:47 AM UTC-4, Sonnenschein wrote:
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.

But then, shouldn't:

c.x = c.x + 10

be rejected as well?

MC


Lanny Ripple

unread,
Oct 23, 2016, 1:37:25 PM10/23/16
to scala-user
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.

Sonnenschein

unread,
Oct 23, 2016, 1:44:40 PM10/23/16
to scala-user
That sounds coherent, too. I suspect this way there is less danger to allow += unintentionally.
Also, when defining an assignment operator, there is nothing told about what you will have on the right side.

Michel Charpentier

unread,
Oct 23, 2016, 2:43:20 PM10/23/16
to scala-user


On Sunday, October 23, 2016 at 1:37:25 PM UTC-4, Lanny Ripple wrote:
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.

You're focusing on the wrong part.  I should have said:  "But then, shouldn't

c.x = 42

be rejected as well?"

If one thinks of

c.x += foo

as syntactic sugar for

c.x = c.x + foo

then why one is rejected but not the other?  Or, put it differently, under what circumstances are the two equivalent?

MC


Oliver Ruebenacker

unread,
Oct 24, 2016, 10:26:29 AM10/24/16
to Michel Charpentier, scala-user

     Hello,

  The actual error is:

scala> c.x += 10
<console>:15: error: value += is not a member of Int
       c.x += 10
           ^

  The intention was to have this mean

  c.x_=(c.x.+(10))

  but the compiler tries to interpret this as:

  (c.x).+=(10)

  There needs to be some rule to choose which one it means that does not require to much looking at classes other than C. Those cases where there is no such ambiguity work either way.

     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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Oliver Ruebenacker
Senior Software Engineer, Diabetes Portal, Broad Institute

Michel Charpentier

unread,
Oct 24, 2016, 10:40:03 AM10/24/16
to scala-user, cha...@gmail.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.

MC
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.

joe.p...@gmail.com

unread,
Oct 24, 2016, 1:47:18 PM10/24/16
to scala-user, cha...@gmail.com


On Monday, October 24, 2016 at 7:40:03 AM UTC-7, Michel Charpentier wrote:
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.

I'm with Michel on this.  The language spec in section 6.12.4 seems clear:

The re-interpretation occurs if the following two conditions are fulfilled.

  1. The left-hand-side l does not have a member named +=, and also cannot be converted by an implicit conversion to a value with a member named +=.
  2. The assignment 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 +.
The error message "value += is not a member of Int" looks to be exactly rule 1, and we know that rule 2 is satisfied.  So, why should where the operations are defined in the inheritance hierarchy affect the decision to apply the assignment operator rewrite rule?

It looks like the compiler and the language spec disagree here.

joe

Reply all
Reply to author
Forward
0 new messages