Hi,
I read somewhere @_ will be used to represent protected instance variables.
What will be the scope of it.
Mystifier
Hi --
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
···
On Fri, 21 Jan 2005, Mystifier wrote:
--
David A. Black
dblack@wobblini.net
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
dblack@wobblini.net
Hi --
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
···
On Fri, 21 Jan 2005, Mystifier wrote:
--
David A. Black
dblack@wobblini.net
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. ?
Hi --
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
···
On Fri, 21 Jan 2005, trans. wrote:
--
David A. Black
dblack@wobblini.net
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.
Hi --
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
···
On Sat, 22 Jan 2005, trans. wrote:
--
David A. Black
dblack@wobblini.net
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.