Interesting - so according to that article, the _ is not operator
overloading, rather it is a whitespace symbol: xyz_= means a method named
"xyz =".
However, that explanation appears to be incomplete, because all of these
seem to work and I don't understand why:
def xyz_=(x: Int) {underlying = x}
def xyz_(x: Int) {underlying = x}
def xyz_abc(x: Int) {underlying = x}
o.xyz = ...; // works with all of the above
If we are going with this convention, then it would be good to fully
understand how it works. Also, if we need to access setters from Java we
would need to provide an explicit setter.
Thanks,
Joel
On Fri, May 25, 2012 at 2:29 PM, Jay Kreps <jay.kr...@gmail.com> wrote:
> Yes, that's my understanding. This blog gives a reasonable overview:
> http://www.dustinmartin.net/2009/10/getters-and-setters-in-scala/
>
> Kind of sad that a year or so in we are just figuring this out, but I guess
> better late then never. :-)
>
> -Jay
>
> On Fri, May 25, 2012 at 2:13 PM, Joel Koshy <jjkosh...@gmail.com> wrote:
>
> > Personally, I like options 3 and 4. (Option 4 more than 3, but I'm not
> sure
> > I follow it correctly - and I did not know that shorthand for
> overloading!
> > So is this right:)
> >
> > class GetSetXYZ {
> > private var underlying = 10
> > def xyz = underlying
> > def xyz_=(x: Int) {underlying = x}
> > }
> >
> > val o = new GetSetXYZ
> > println(o.xyz) // 10
> > o.xyz=5
> > println(o.xyz) // 5
> >
> > On Fri, May 25, 2012 at 10:17 AM, Jay Kreps <jay.kr...@gmail.com> wrote:
> >
> > > Oh no, you are no using xyz_() you are overriding =. So you define
> > > xyz_=(x:Int)
> > > but to call it you do
> > > o.xyz = 5
> > > The reason this is nice is because you can start with a simple
> > > var xyz
> > > and not need any getter/setter. Then later when you need to change the
> > > behavior of the get you make
> > > def xyz = ...
> > > and none of the calling code changes. Later still you decide you need
> to
> > > override the setter you do
> > > def xyz_=(x: Int)...
> > > and that overrides o.xyz=5, again without changing the calling code.
> > >
> > > Basically the point is that scala generates these getters and setters
> no
> > > matter what so you might as well use the official scala mechanism.
> > >
> > > Since I am only semi-scala literate any of the above may be wrong.
> > >
> > > -Jay
> > >
> > > On Fri, May 25, 2012 at 9:42 AM, Jun Rao <jun...@gmail.com> wrote:
> > >
> > > > I think separating out the getter and setter makes the implementation
> > > > cleaner. I am not sure how intuitive it is to use xyz_() as the
> setter,
> > > > although it is concise.
> > > >
> > > > Thanks,
> > > >
> > > > Jun
> > > >
> > > > On Tue, May 22, 2012 at 9:13 PM, Jay Kreps <jay.kr...@gmail.com>
> > wrote:
> > > >
> > > > > We are a little inconsistent in our use of setters and getters. I
> > think
> > > > for
> > > > > the most part well-written code shouldn't have too many setters and
> > > > getters
> > > > > (especially setters) since they expose internal details of the
> > object.
> > > > But
> > > > > sometimes you need them. I see three common conventions:
> > > > >
> > > > > 1. Java-style getXyz() and/or setXyz() method
> > > > > 2. xyz() plus semantically named setter that describes what it
> > does.
> > > > > 3. In some newer code I see xyz(x: Option[Int])
> > > > >
> > > > > There is also a forth option. My understanding of the proper scala
> > > idiom
> > > > > was actually that scala automatically created get and set methods
> for
> > > > you,
> > > > > and the appropriate thing to do is to override these. This is
> > described
> > > > > here:
> > > > http://www.codecommit.com/blog/scala/scala-for-java-refugees-part-2
> > > > >
> > > > > Essentially you can start with just
> > > > >
> > > > > val xyz = ...
> > > > >
> > > > > Then later if you want to override the getter you would do
> > > > >
> > > > > private val x = ...
> > > > >
> > > > > // getter
> > > > >
> > > > > def xyz = if(check_something) x else throw new
> IllegalStateException
> > > > >
> > > > > Then if you also want to add a setter you do
> > > > >
> > > > > private val x = ...
> > > > >
> > > > > def xyz = if(check_something) x else throw new
> IllegalStateException
> > > > > def xyz_=(x: Int) {xyz = x}
> > > > >
> > > > > Let's pick one of these and refactor towards it as we see code that
> > > > doesn't
> > > > > match. My vote would be for option 4.
> > > > >
> > > > > -Jay
> > > > >
> > > >
> > >
> >
>
