getter / setter questions

[Michael Wohlwend]

Hi,

one can define getters and setters without an associated field. But why does the
setter has to have the same name as the getter?
This compiles and works:
class X { private var v = 0; def get = v; def get_= (i:Int)  { v = i } }

This compiles and gives a runtime error:
class X { private var v = 0; def get = v; def put_= (i:Int)  { v = i } }

val k = new X
k: X = X@679e3bdd
scala> k.put = 3
<console>:6: error: value put is not a member of X
       k.put = 3


which seems not true to me :-)



thanks for answering,
 Michael

[Daniel Sobral]

That's because "var v" is translated into a field, a getter and a setter. I'll take a small detour to explain that.

One important thing in Scala is preserving the interface, no matter if a field is defined with def, val or var, so it can change from one to the other without impact on the user code.

Also, a def can be overridden by a val on subclasses.

Now, while this would be easy to do if Scala was the only user code, it has to interface with Java as well. In Java, methods and fields are syntactically different, so any change from one to the other would break Java client code.

Therefore, what Scala actually does when you declare "var v" is to compile that into a v field, a v() method, and a v_= method.

Which is why you can't both declare "var v" and "def v". It's the same namespace.

But that's a confusion mostly made by Java programmers. Scala-wise, it's pretty simple: val, var and def are in the same namespace. Period.

On Tue, Jul 7, 2009 at 7:49 PM, Micha <micha-1@...> wrote:

Hi,

one can define getters and setters without an associated field. But why does the
setter has to have the same name as the getter?
This compiles and works:
class X { private var v = 0; def get = v; def get_= (i:Int)  { v = i } }

This compiles and gives a runtime error:
class X { private var v = 0; def get = v; def put_= (i:Int)  { v = i } }

val k = new X
k: X = X@679e3bdd
scala> k.put = 3
<console>:6: error: value put is not a member of X
      k.put = 3


which seems not true to me :-)



thanks for answering,
 Michael

--
Daniel C. Sobral

Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.

[Naftoli Gugenheim]

Of course also included are member object singletons (although they probably fall into the val category).

-------------------------------------
Daniel Sobral<dcsobral@...> wrote:

That's because "var v" is translated into a field, a getter and a setter.
I'll take a small detour to explain that.
One important thing in Scala is preserving the interface, no matter if a
field is defined with def, val or var, so it can change from one to the
other without impact on the user code.

Also, a def can be overridden by a val on subclasses.

Now, while this would be easy to do if Scala was the only user code, it has
to interface with Java as well. In Java, methods and fields are
syntactically different, so any change from one to the other would break
Java client code.

Therefore, what Scala actually does when you declare "var v" is to compile
that into a v field, a v() method, and a v_= method.

Which is why you can't both declare "var v" and "def v". It's the same
namespace.

But that's a confusion mostly made by Java programmers. Scala-wise, it's
pretty simple: val, var and def are in the same namespace. Period.

On Tue, Jul 7, 2009 at 7:49 PM, Micha <micha-1@...> wrote:

> Hi,
>
> one can define getters and setters without an associated field. But why
> does the
> setter has to have the same name as the getter?
> This compiles and works:
> class X { private var v = 0; def get = v; def get_= (i:Int)  { v = i } }
>
> This compiles and gives a runtime error:
> class X { private var v = 0; def get = v; def put_= (i:Int)  { v = i } }
>
> val k = new X
> k: X = X@679e3bdd
> scala> k.put = 3
> <console>:6: error: value put is not a member of X
>       k.put = 3
>
>
> which seems not true to me :-)
>
>
>
> thanks for answering,
>  Michael
>
>
>
>

--
Daniel C. Sobral

Something I learned in academia: there are three kinds of academic reviews:
review by name, review by reference and review by value.

[Michael Wohlwend]

Am Wednesday 08 July 2009 01:36:38 schrieb Daniel Sobral:
> Now, while this would be easy to do if Scala was the only user code, it has
> to interface with Java as well. In Java, methods and fields are
> syntactically different, so any change from one to the other would break
> Java client code.
>
> Therefore, what Scala actually does when you declare "var v" is to compile
> that into a v field, a v() method, and a v_= method.
> Which is why you can't both declare "var v" and "def v". It's the same
> namespace.

no problem with that. I was wondering why the setter has to have the same name
as the getter, which isn't obvious for me, you even don't need an associated
field to set. But the compatibility to java seams the reason.



thanks
 Michael

[Ricky Clarkson]

The setter doesn't have the same name as the getter.  "v_" != "v"

I don't think it's a bad naming scheme.

2009/7/8 Michael <micha-1@...>:

> Am Wednesday 08 July 2009 01:36:38 schrieb Daniel Sobral:
>> Now, while this would be easy to do if Scala was the only user code, it has
>> to interface with Java as well. In Java, methods and fields are
>> syntactically different, so any change from one to the other would break
>> Java client code.
>>
>> Therefore, what Scala actually does when you declare "var v" is to compile
>> that into a v field, a v() method, and a v_= method.
>> Which is why you can't both declare "var v" and "def v". It's the same
>> namespace.
>
> no problem with that. I was wondering why the setter has to have the same name
> as the getter, which isn't obvious for me, you even don't need an associated
> field to set. But the compatibility to java seams the reason.
>
>
>
> thanks
>  Michael
>
>

--
Ricky Clarkson
Java Programmer, AD Holdings
[phone]
Skype: ricky_clarkson
Google Talk: ricky.clarkson@...

[Michael Wohlwend]

Am Wednesday 08 July 2009 10:58:57 schrieb Ricky Clarkson:
> The setter doesn't have the same name as the getter.  "v_" != "v"

yes, it's only that foo and foo_ works, but bar und foo_ doesn't work, so the
names have to be the same, expect for the underline. But this isn't obvious.

 Michael

[Ricky Clarkson]

I think it's reasonably obvious that bar isn't the name of a setter for foo.

2009/7/8 Michael <micha-1@...>:
> Am Wednesday 08 July 2009 10:58:57 schrieb Ricky Clarkson:
>> The setter doesn't have the same name as the getter.  "v_" != "v"
>
> yes, it's only that foo and foo_ works, but bar und foo_ doesn't work, so the
> names have to be the same, expect for the underline. But this isn't obvious.
>
>  Michael
>



--
Ricky Clarkson
Java Programmer, AD Holdings
[phone]
Skype: ricky_clarkson
Google Talk: ricky.clarkson@...

[Michael Wohlwend]

Am Wednesday 08 July 2009 11:16:41 schrieb Ricky Clarkson:
> I think it's reasonably obvious that bar isn't the name of a setter for
> foo.

a setter can be just some function, like written here:
on page 392 and 393 of the "Programming in Scala" book there is an example
where they define conversion functions to and from fahrenheit to and from
celsius with a getter and a setter function. This looked to me like I can
choose the names for getters and setters arbitray. But maybe just my english
sucks and I understood something which isn't there :-)

cheers
 Michael

[Daniel Sobral]

Ah, I understand now! Indeed, that is curious. The book says the following on assinments:

 

The interpretation of an assignment to a simple variable

x = e depends on the

definition of

x. If x denotes a mutable variable, then the assignment changes the

current value of

x to be the result of evaluating the expression e. The type of e is

expected to conform to the type of

x. If x is a parameterless function defined in

some template, and the same template contains a setter function

x_= as member,

then the assignment

x = e is interpreted as the invocation x_=(e ) of that setter

function. Analogously, an assignment

f .x = e to a parameterless function x is

interpreted as the invocation

f .x_=(e ).

 

So, here it is: "If x is a parameterless function defined in some template, and the same template contains a setter function x_= as member". The same-name getter is a requirement. It's probably a matter of consistency: getters and setters are a way to make something look like a var, while hiding the actual implementation.

On Wed, Jul 8, 2009 at 6:37 AM, Michael <micha-1@...> wrote:

Am Wednesday 08 July 2009 11:16:41 schrieb Ricky Clarkson:

> I think it's reasonably obvious that bar isn't the name of a setter for
> foo.

a setter can be just some function, like written here:
on page 392 and 393 of the "Programming in Scala" book there is an example
where they define conversion functions to and from fahrenheit to and from
celsius with a getter and a setter function. This looked to me like I can
choose the names for getters and setters arbitray. But maybe just my english
sucks and I understood something which isn't there :-)

cheers
 Michael

--
Daniel C. Sobral

Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.

[Naftoli Gugenheim]

Maybe because if not for the requirement, if you had a var and a _= method with the same base name assignment would be ambiguous? And if it was a val it would be confusing to a user. Like this there can't be a var/val if there is a def.

-------------------------------------
Daniel Sobral<dcsobral@...> wrote:

Ah, I understand now! Indeed, that is curious. The book says the following
on assinments:


The interpretation of an assignment to a simple variable
*x *= *e *depends on the

definition of
*x*. If *x *denotes a mutable variable, then the assignment changes the

current value of
*x *to be the result of evaluating the expression *e*. The type of *e *is

expected to conform to the type of
*x*. If *x *is a parameterless function defined in

some template, and the same template contains a setter function
*x*_= as member,

then the assignment
*x *= *e *is interpreted as the invocation *x*_=(*e *) of that setter

function. Analogously, an assignment
*f *.*x *= *e *to a parameterless function *x *is

interpreted as the invocation
*f *.*x*_=(*e *).

  So, here it is: "If *x *is a parameterless function defined in some
template, and the same template contains a setter function *x*_= as member".
The same-name getter is a requirement. It's probably a matter of
consistency: getters and setters are a way to make something look like a
var, while hiding the actual implementation.


On Wed, Jul 8, 2009 at 6:37 AM, Michael <micha-1@...> wrote:

> Am Wednesday 08 July 2009 11:16:41 schrieb Ricky Clarkson:
> > I think it's reasonably obvious that bar isn't the name of a setter for
> > foo.
>
> a setter can be just some function, like written here:
> on page 392 and 393 of the "Programming in Scala" book there is an example
> where they define conversion functions to and from fahrenheit to and from
> celsius with a getter and a setter function. This looked to me like I can
> choose the names for getters and setters arbitray. But maybe just my
> english
> sucks and I understood something which isn't there :-)
>
> cheers
>  Michael
>

--
Daniel C. Sobral

Something I learned in academia: there are three kinds of academic reviews:
review by name, review by reference and review by value.