Preferred Instance Variable Access Method

Discussion in 'Ruby' started by Bill Atkins, Apr 7, 2004.

  1. Bill Atkins

    Bill Atkins Guest

    What's the preferred way of accessing a class's instance variables?
    Almost every example I've seen uses the @ form:

    class Test
    def var_set
    @var = 3
    end
    def var_modify(v)
    @vare = 34
    return @var
    end
    end

    t = Test.new
    t.var_set
    puts t.var_modify

    The obvious problem with this can be seen in Test#var_modify. The
    programmer meant to change the value of @var but made a typo and broke
    his code. The program prints 3 instead of 34.

    The way around this is through accessors:

    class Test
    attr_accessor :var
    def var_set
    self.var = 3
    end
    def var_modify
    self.vare = 34
    return self.var
    end
    end

    This produces an error that can be caught.

    My question is this: why is this form so rarely used? Is it the extra
    typing? Is it somehow un-Rubyesque? It seems like a good way to
    catch silly errors like the one above.

    Thanks,
    Bill
     
    Bill Atkins, Apr 7, 2004
    #1
    1. Advertising

  2. Hi --

    On Thu, 8 Apr 2004, Bill Atkins wrote:

    > What's the preferred way of accessing a class's instance variables?
    > Almost every example I've seen uses the @ form:
    >
    > class Test
    > def var_set
    > @var = 3
    > end
    > def var_modify(v)
    > @vare = 34
    > return @var
    > end
    > end
    >
    > t = Test.new
    > t.var_set
    > puts t.var_modify
    >
    > The obvious problem with this can be seen in Test#var_modify. The
    > programmer meant to change the value of @var but made a typo and broke
    > his code. The program prints 3 instead of 34.
    >
    > The way around this is through accessors:
    >
    > class Test
    > attr_accessor :var
    > def var_set
    > self.var = 3
    > end
    > def var_modify
    > self.vare = 34
    > return self.var
    > end
    > end
    >
    > This produces an error that can be caught.
    >
    > My question is this: why is this form so rarely used? Is it the extra
    > typing? Is it somehow un-Rubyesque? It seems like a good way to
    > catch silly errors like the one above.


    I'm a little puzzled by your example.... Did you mean var_modify to
    take an argument? (It does in your first example, though the argument
    isn't used.)

    Assuming you do mean "def var_modify(v); self.var=v; end" .... That
    is indeed somewhat unidiomatic. From the point of view of the calling
    code, it's more idiomatic to do:

    obj.var = 100

    than

    obj.var_modify(100)

    In fact it's so Rubyesque that Matz has provided the attr_* family of
    method-writing shortcuts :) Wrapping them in further layers of set/get
    methods is redundant.

    As for the error -- there's no more or less danger here than in many
    other places where you use variable names. Consider this:

    def blah(x)
    y = 1
    if x > 5
    return y
    else
    return yy * 2
    end
    end

    Of course yy is a typo, but you'll never know until you call the method
    with x <= 5.

    That (among other reasons) is why there's so much emphasis placed in the
    Ruby community on unit testing.


    David

    --
    David A. Black
     
    David A. Black, Apr 7, 2004
    #2
    1. Advertising

  3. Hi,

    At 05:34 08/04/2004 +0900, you wrote:
    What's the preferred way of accessing a class's instance variables?

    I tend to use @var instead of self.var (I guess var() would work, and
    var too).

    I see two advantages:
    1) Faster (I never benchmarked however)
    2) Lines starting with @ are like methods with ! at the end =>
    Draw the attention to probable side effect on obj's state.

    I do agree that typos can be an issue. There is warning however,
    with ruby -w (that sometimes warns for some valid constructions
    of mine, I guess defined? could help me avoid that).

    Refering to a recent thread, I may add that self.var seems slightly
    Python-ish.

    I would personally prefer .var but languages with configurable style/
    syntax are rare these days (missing C's #define).

    Nota: Ruby let you add instance variables on the fly, such variables
    default to nil. Maybe some "strict" pragma/hint would be welcome, paving
    the way to some optimization where access to instance variables could
    be direct versus thru an hash.

    FWIW

    Jean-Hugues

    EOM

    At 05:34 08/04/2004 +0900, you wrote:
    >What's the preferred way of accessing a class's instance variables?
    >Almost every example I've seen uses the @ form:
    >
    >class Test
    > def var_set
    > @var = 3
    > end
    > def var_modify(v)
    > @vare = 34
    > return @var
    > end
    >end
    >
    >t = Test.new
    >t.var_set
    >puts t.var_modify
    >
    >The obvious problem with this can be seen in Test#var_modify. The
    >programmer meant to change the value of @var but made a typo and broke
    >his code. The program prints 3 instead of 34.
    >
    >The way around this is through accessors:
    >
    >class Test
    > attr_accessor :var
    > def var_set
    > self.var = 3
    > end
    > def var_modify
    > self.vare = 34
    > return self.var
    > end
    >end
    >
    >This produces an error that can be caught.
    >
    >My question is this: why is this form so rarely used? Is it the extra
    >typing? Is it somehow un-Rubyesque? It seems like a good way to
    >catch silly errors like the one above.
    >
    >Thanks,
    >Bill


    -------------------------------------------------------------------------
    Web: http://hdl.handle.net/1030.37/1.1
    Phone: +33 (0) 4 92 27 74 17
     
    Jean-Hugues ROBERT, Apr 7, 2004
    #3
  4. Hi --

    Jean-Hugues ROBERT <> writes:

    > Hi,
    >
    > At 05:34 08/04/2004 +0900, you wrote:
    > What's the preferred way of accessing a class's instance variables?
    >
    > I tend to use @var instead of self.var (I guess var() would work, and
    > var too).
    >
    > I see two advantages:
    > 1) Faster (I never benchmarked however)
    > 2) Lines starting with @ are like methods with ! at the end =>
    > Draw the attention to probable side effect on obj's state.


    Don't forget, though, that these techniques (@var vs. self.var) are
    only equivalent in certain simple (and common, but not unique) cases.
    If you're doing anything more complex, like:

    def var=(x)
    @var = x.to_s.upcase
    end

    then you don't have a choice; you have to go through the method
    (self.var = y) rather than just doing @var = y, elsewhere in the
    class.

    (The original question involved another level of remove (wrapping the
    attr_* methods themselves in "var_get" and "var_modify" methods, but
    wherever they occur, @var = and self.var= are not automatically
    equivalent.)

    This also points to a constraint on Eric's point about not wanting to
    worry about forgetting the 'self' -- namely, that you can only do that
    when you know for sure that #var= is a simple set method for @var.
    Also, the @var = y technique could come back to bite you if you
    reimplement the setter method and haven't routed your assignments
    through it:

    attr_accessor :var
    def initialize(y)
    @var = y # OK until you reimplement #var= to do something
    end # non-simple, at which point you have to remember
    # that you assigned directly to @var here.

    (I would have quoted Eric directly except I'm posting directly to
    comp.lang.ruby, because of the gateway problems, and Eric's posts
    don't seem to be making it here :-(


    David

    --
    David A. Black
     
    David Alan Black, Apr 8, 2004
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Matt
    Replies:
    1
    Views:
    511
    Kevin Spencer
    Feb 11, 2005
  2. Dave Benjamin
    Replies:
    0
    Views:
    321
    Dave Benjamin
    Oct 14, 2003
  3. David Garamond
    Replies:
    5
    Views:
    275
    Ara.T.Howard
    Jun 8, 2004
  4. Raj Singh
    Replies:
    2
    Views:
    216
    Rick DeNatale
    May 29, 2008
  5. Greg Hauptmann
    Replies:
    9
    Views:
    266
    Loren Segal
    Jun 16, 2008
Loading...

Share This Page