Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Kafka, mail # dev - setters and getters


Copy link to this message
-
Re: setters and getters
Joel Koshy 2012-05-25, 21:14
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
>> > >
>> >
>>
>
>