Another advantage of 4 over 3 is that we don't need the case match to deal
with the Option.
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
>> > >
>> >
>>
>
>
