Protected instance variables

Discussion in 'Ruby' started by Mystifier, Jan 21, 2005.

  1. Mystifier

    Mystifier Guest

    ------=_NextPart_000_0031_01C4FFDF.E9602A40
    Content-Type: text/plain;
    charset="us-ascii"
    Content-Transfer-Encoding: 7bit

    Hi,

    I read somewhere @_ will be used to represent protected instance variables.
    What will be the scope of it.


    Mystifier

    ------=_NextPart_000_0031_01C4FFDF.E9602A40--
     
    Mystifier, Jan 21, 2005
    #1
    1. Advertising

  2. Hi --

    On Fri, 21 Jan 2005, Mystifier wrote:

    > Hi,
    >
    > I read somewhere @_ will be used to represent protected instance variables.
    > What will be the scope of it.


    My understanding is that they'll be module/class-scoped:

    module M
    def a
    @_var = 1
    end
    end

    class C
    include M
    def b
    puts @_var
    end
    end

    c = C.new
    c.a
    c.b # nil

    I could be getting it wrong, though.

    Also I believe that Matz hasn't decided whether it will be @_var or
    @var. If the latter, then @_var would be for non-protected ones. My
    hatred of extra punctuation is such that I would rather see them all
    behave the same way (whatever it is) and be @var.


    David

    --
    David A. Black
     
    David A. Black, Jan 21, 2005
    #2
    1. Advertising

  3. Mystifier

    Mystifier Guest

    By going with C++ convention, currently @vars are protected, new ones will
    be private. Right?

    Mystifier

    -----Original Message-----
    From: dblack@wobblini [mailto:dblack@wobblini] On Behalf Of David A. Black
    Sent: Friday, January 21, 2005 6:42 PM
    To: ruby-talk ML
    Subject: Re: Protected instance variables


    Hi --

    On Fri, 21 Jan 2005, Mystifier wrote:

    > Hi,
    >
    > I read somewhere @_ will be used to represent protected instance

    variables.
    > What will be the scope of it.


    My understanding is that they'll be module/class-scoped:

    module M
    def a
    @_var = 1
    end
    end

    class C
    include M
    def b
    puts @_var
    end
    end

    c = C.new
    c.a
    c.b # nil

    I could be getting it wrong, though.

    Also I believe that Matz hasn't decided whether it will be @_var or
    @var. If the latter, then @_var would be for non-protected ones. My
    hatred of extra punctuation is such that I would rather see them all
    behave the same way (whatever it is) and be @var.


    David

    --
    David A. Black
     
    Mystifier, Jan 21, 2005
    #3
  4. Hi --

    On Fri, 21 Jan 2005, Mystifier wrote:

    > By going with C++ convention, currently @vars are protected, new ones will
    > be private. Right?


    I'm not sure whether it maps onto C++, but I don't think that's a
    goal. My understanding was that the problem was accidental
    overwriting of instance variables -- for example, if you include a
    module but haven't seen the code so you don't know what names the
    author used for instance variables. So having them be
    [protected,private] (not sure which is the right term) would mean you
    could make up your own instance variable names in class or module
    scope and not have to worry.


    David

    --
    David A. Black
     
    David A. Black, Jan 21, 2005
    #4
  5. Mystifier

    trans. Guest

    David wrote:
    So having them be [protected,private] (not sure which is
    the right term) would mean you could make up your own
    instance variable names in class or module scope and not
    have to worry.

    Hmm... That certainly seems like a good idea. And then you'd use
    accessors to get at those on different levels. But attribute names
    (i.e. method names for accessing those instance vars) would still come
    into conflict, which partially of defeats the purpose. ?
     
    trans., Jan 21, 2005
    #5
  6. Hi --

    On Fri, 21 Jan 2005, trans. wrote:

    > David wrote:
    > So having them be [protected,private] (not sure which is
    > the right term) would mean you could make up your own
    > instance variable names in class or module scope and not
    > have to worry.
    >
    > Hmm... That certainly seems like a good idea. And then you'd use
    > accessors to get at those on different levels.


    If you want. Or they may just be used to store state privately.

    > But attribute names
    > (i.e. method names for accessing those instance vars) would still come
    > into conflict, which partially of defeats the purpose. ?


    That shouldn't be a problem, because if a module defines an accessor
    method, that will be documented and if you're writing a class that
    includes that module, you'll know not to override it unless you want
    to (as with other methods).


    David

    --
    David A. Black
     
    David A. Black, Jan 21, 2005
    #6
  7. Mystifier

    trans. Guest

    Okay, that makes sense for public attribute methods. Does it apply as
    well to private and protected?

    FYI, I'm thinking about @vars always being "local" and no such thing as
    @_ non-locals, rather accessors would be needed. It's come up before
    but I don't recall anyone laying out the pros and cons really.
     
    trans., Jan 21, 2005
    #7
  8. Hi --

    On Sat, 22 Jan 2005, trans. wrote:

    > Okay, that makes sense for public attribute methods. Does it apply as
    > well to private and protected?


    I would think so. If you're going to do:

    class C
    include M
    def x
    # ...
    end
    end

    I think you really have to know whether there's an x method in M, at
    any privacy level.


    David

    --
    David A. Black
     
    David A. Black, Jan 21, 2005
    #8
  9. Mystifier

    trans. Guest

    I see. Thanks. (And a good reason to be sure to document even ones
    non-public methods then.)

    Actually that helps me understand the fore mentioned alternate concept
    of having only pure locals. Right now, we have instance vars that are
    accssable from anywhere in the hierarchy. That's like a submethod being
    able to access the local vars of its super!

    Nonetheless, I recall some were dead set against the idea. Perhaps
    unfortuately, I thinks most of us have become quite accustomed to it.
     
    trans., Jan 21, 2005
    #9
    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. Andreas Klemt
    Replies:
    2
    Views:
    562
    Andreas Klemt
    Jul 5, 2003
  2. Replies:
    10
    Views:
    35,902
    jporter892
    Jun 6, 2011
  3. Suzanne Vogel
    Replies:
    5
    Views:
    2,361
    Dan W.
    Dec 9, 2003
  4. Gerd Schmitt

    protected by instance, not by type?

    Gerd Schmitt, Sep 28, 2004, in forum: C++
    Replies:
    1
    Views:
    356
    John Harrison
    Sep 28, 2004
  5. Eric D.
    Replies:
    3
    Views:
    180
    Jeremy Henty
    Feb 1, 2006
Loading...

Share This Page