Attempted roadmap of future instance variables

ruby-talk
21

Are @_var variables just basically private instance variables (as in private
variables in C++?

They were renamed "class local" precisely to make in sort that you don't
make confusion with C++ private/protected

Guy Decoux

22

Hi –

“Yukihiro Matsumoto” matz@ruby-lang.org schrieb im Newsbeitrag
news:1070389195.767662.15370.nullmailer@picachu.netlab.jp…

Hi,

OK so the jist of it is that @_var variables are stored with the class
of
the instance but the class has no access to that. That is all. Right?

No. @_var variables are stored in the instance, but they are
accessible only from methods defined in the same class.

Still a number of questions arise to me: How then are @_ variables treated
with respect to methods instance_variables, instance_variable_set and
instance_variable_get? Are they ignored and there is a second set of
methods that receives the class as argument (e.g.
instance_local_variables, instance_local_variable_get,
instance_local_variable_set)

I assume they work as always, constrained only by the scope. So:

class A
def m
instance_variable_set(“@x”,1)
instance_variable_set(“@_y”,2)
end

def n
  # @x and @_y, if used here, are the same objects here as above
end

end

class B
def mm
# @x same as above
# @_y different (class [B] local)
end
end

If so, what, if they are defined in an instance’s private class like this:

class <<obj
def get_foo; @_foo; end
def set_foo(f); @_foo = f; end
end

Do we use the instance instead of the class as method argument to those
methods (see above) to get access to them via those methods? If so, how
is that disambiguited if obj is a class?

Applying the rule: @_ variables are visible only from methods defined
in the same class, I guess that would mean if you did:

class A
def x; @x; end
def x=(y); @x=y; end
def _x; @_x; end
def _x=(y); @_x=y; end
end

a = A.new

class << a
def showx; @x; end # same @x as in A#x and A#x=
def show_x; @_x; end # different @_x (same object (a) but defined
in a method in a different class
(a’s singleton as opposed to A)
end

I think (?) this is similar to Guy’s example with singleton methods
(which I’m still puzzling over :slight_smile:

Or do we make them unique by modifying the identifier, e.g. @_var becomes
@Foo:_var if it was defined in class Foo?

I don’t think so; that kind of direct access to instance vars would
break privacy and encapsulation.

David

···

On Wed, 3 Dec 2003, Robert Klemme wrote:

In message “Re: Attempted roadmap of future instance variables…” > > on 03/12/03, Steve Tuckner STUCKNER@MULTITECH.COM writes:

–
David A. Black
dblack@wobblini.net

23

I think (?) this is similar to Guy's example with singleton methods
(which I'm still puzzling over :slight_smile:

Well, my example can be re-written like this

   class A
      def self.set
         @m = 'A::m'
         @_m = 'A::_m'
      end

      def self.get
         p @m, @_m
      end
   end

   class B < A
      def self.set
         @m = 'B::m'
         @_m = 'B::_m'
      end

      def self.get
         p @m, @_m
         super
      end
   end

   B.set
   B.get

This is because A::set was never called in B::set that I expect that @_m
give nil when super is called

@_m is initialized only inside the class B

Guy Decoux

24

So these @_instace vars are giving us dynamic scoping in one instance right?

class Super
@_var = 0
def get
@_var
end
end

class Sub < Super
@_var = 1;
end

Super.new.get
-> 1

This occurs because @_var is different in each of these classes but the get
method is still inherited.

Or am I missing the picture here?

I haven’t played with Ruby in terms of the objects quite as much, so I may
not be following correctly.

Charles Comstock

25

“David A. Black” dblack@wobblini.net schrieb im Newsbeitrag
news:Pine.LNX.4.44.0312030558560.27096-100000@wobblini.net…

Hi –

“Yukihiro Matsumoto” matz@ruby-lang.org schrieb im Newsbeitrag
news:1070389195.767662.15370.nullmailer@picachu.netlab.jp…

Hi,

OK so the jist of it is that @_var variables are stored with the
class
of
the instance but the class has no access to that. That is all.
Right?

No. @_var variables are stored in the instance, but they are
accessible only from methods defined in the same class.

Still a number of questions arise to me: How then are @_ variables
treated
with respect to methods instance_variables, instance_variable_set and
instance_variable_get? Are they ignored and there is a second set of
methods that receives the class as argument (e.g.
instance_local_variables, instance_local_variable_get,
instance_local_variable_set)

I assume they work as always, constrained only by the scope. So:

class A
def m
instance_variable_set(“@x”,1)
instance_variable_set(“@_y”,2)
end

This is all well, but what if you invoke those methods from the outside?

def n
  # @x and @_y, if used here, are the same objects here as above
end

end

class B
def mm
# @x same as above
# @_y different (class [B] local)
end
end

If so, what, if they are defined in an instance’s private class like
this:

class <<obj
def get_foo; @_foo; end
def set_foo(f); @_foo = f; end
end

Do we use the instance instead of the class as method argument to
those
methods (see above) to get access to them via those methods? If so,
how
is that disambiguited if obj is a class?

Applying the rule: @_ variables are visible only from methods defined
in the same class, I guess that would mean if you did:

class A
def x; @x; end
def x=(y); @x=y; end
def _x; @_x; end
def _x=(y); @_x=y; end
end

a = A.new

class << a
def showx; @x; end # same @x as in A#x and A#x=
def show_x; @_x; end # different @_x (same object (a) but defined
in a method in a different
class
(a’s singleton as opposed to
A)
end

I think (?) this is similar to Guy’s example with singleton methods
(which I’m still puzzling over :slight_smile:

Or do we make them unique by modifying the identifier, e.g. @_var
becomes
@Foo:_var if it was defined in class Foo?

I don’t think so; that kind of direct access to instance vars would
break privacy and encapsulation.

??? That’s broken already since I can invoke instance_variable_get from
the outside already now.

Cheers

robert
···

On Wed, 3 Dec 2003, Robert Klemme wrote:

In message “Re: Attempted roadmap of future instance variables…” > > > on 03/12/03, Steve Tuckner STUCKNER@MULTITECH.COM writes:

26

So these @_instace vars are giving us dynamic scoping in one instance right?

@_instance are instance variables (they are described in the slide 13)

class Super
  @_var = 0

  this is an instance variable for the class Super

  def get
    @_var

this is an instance variable for an *instance* of Super. This mean that
this variable is different than the previous one

  end
end

Guy Decoux

27

Hi –

“David A. Black” dblack@wobblini.net schrieb im Newsbeitrag

class A
def m
instance_variable_set(“@x”,1)
instance_variable_set(“@_y”,2)
end

This is all well, but what if you invoke those methods from the outside?

OK, I think this illustrates your question (and a conjectural answer
:slight_smile:

Given this:

class M
def y1
@_y
end
end

class N < M
def y2
@_y
end
end

if we do this:

n = N.new
n.instance_variable_set(“@_y”,100)

which @_y got set? In other words, what will the two @_y-getters give
us?

puts n.y1 # M’s view of n’s @_y
puts n.y2 # N’s view of n’s @_y

I would tend to assume that we’d get

nil
100

i.e., that instance_variable_set, if it has to choose a class-local
scope as well as instance scope, would choose the object’s “birth
class”. But I’m not certain.

David

···

On Thu, 4 Dec 2003, Robert Klemme wrote:

–
David A. Black
dblack@wobblini.net

28

ts wrote:
…

Well, my example can be re-written like this

class A
def self.set
@m = ‘A::m’
@_m = ‘A::_m’
end

  def self.get
     p @m, @_m
  end

end

class B < A
def self.set
@m = ‘B::m’
@_m = ‘B::_m’
end

  def self.get
     p @m, @_m
     super
  end

end

B.set
B.get

This is because A::set was never called in B::set that I
expect that @_m give nil when super is called

The more general question is if the “class localness”
should be extended to singleton class sub-classing (in
your example the meta class of A and B respectively)
or if should be restricted to “regular” sub-classing.

/Christoph

29

Right I got that from before,

The thing is in most static languages they check to make sure your not using
an instance variable in one class that has the same name in one above it.
In ruby we are allowing this, in fact making sure of it, and thus we are
getting a dynamic scoping situation out of it. Or perhaps dynamic scoping
is the wrong word, but the binding on which variable we are using allows
scoping “fall through” mechanics.

Charles Comstock

···

-----Original Message-----
From: ts [mailto:decoux@moulon.inra.fr]
Sent: Wednesday, December 03, 2003 10:24 AM
To: ruby-talk ML
Cc: ruby-talk@ruby-lang.org
Subject: Re: Attempted roadmap of future instance variables…

So these @_instace vars are giving us dynamic scoping in one instance
right?

@_instance are instance variables (they are described in the slide 13)

class Super
@_var = 0

this is an instance variable for the class Super

def get
  @_var

this is an instance variable for an instance of Super. This mean that
this variable is different than the previous one

end

end

Guy Decoux

30

The more general question is if the "class localness"
should be extended to singleton class sub-classing (in
your example the meta class of A and B respectively)

                    ^^^^^^^^^^

I don't know what is this :-))

or if should be restricted to "regular" sub-classing.

and a more general question is : instance variable must be implemented for
class or only restricted for instance.

Guy Decoux

31

I would think they would be visible to singletons, since singletons, as they
currently stand, are implict --that is to say, their namespace is
“invisible”. But then again, I’m not to keen on this later fact anyway.

2 cents,
T.

···

On Friday 05 December 2003 01:17 am, Christoph wrote:

The more general question is if the “class localness”
should be extended to singleton class sub-classing (in
your example the meta class of A and B respectively)
or if should be restricted to “regular” sub-classing.

32

Hi –

···

On Fri, 5 Dec 2003, ts wrote:

The more general question is if the “class localness”
should be extended to singleton class sub-classing (in
your example the meta class of A and B respectively)
^^^^^^^^^^

I don’t know what is this :-))

or if should be restricted to “regular” sub-classing.

and a more general question is : instance variable must be implemented for
class or only restricted for instance.

I’m not sure I understand. Whatever the behavior is, wouldn’t it be
the same for all objects?

David

–
David A. Black
dblack@wobblini.net

33

ts wrote:
…

The more general question is if the “class localness”
should be extended to singleton class sub-classing (in
your example
the meta class of A and B respectively)
^^^^^^^^^^

I don’t know what is this :-))

metaA = class << A; self end

To give you another example of what I am trying to say lets say

class A
def initialize
@_test = “test”
end
def test
@_var
end
end

a = A.new

p a.test # “test”

class << a
def test
@_var
end
end

p a.test # nil or “test”

or if should be restricted to “regular” sub-classing.

and a more general question is : instance variable must be
implemented for class or only restricted for instance.

Now, I am not quite sure what you mean :slight_smile:

/Christoph

34

I'm not sure I understand. Whatever the behavior is, wouldn't it be
the same for all objects?

This is *exactly* what I was trying to say :-)))

Guy Decoux

35

I wrote:
…

To give you another example of what I am trying to say lets say

class A
def initialize
@_test = “test”
@_var = “test”
end
def test
@_var
end
end
…

/Christoph

36

metaA = class << A; self end

I've understood that you want to make reference to the singleton class.

p a.test # nil or "test"

ask matz

Guy Decoux

37

Hi –

To give you another example of what I am trying to say lets say

class A
def initialize
@_var = “test”
end
def test
@_var
end
end

a = A.new

p a.test # “test”

class << a
def test
@_var
end
end

p a.test # nil or “test”

I would assume nil. If it’s “test”, then what that means is that
singleton classes are not allowed to take advantage of class-local
scope the same way other classes are, which seems arbitrary. It
would also have implications for class methods:

class Class
def something
# some use of @_var, thinking it’s class-local
end
end

class A
def A.m
# any use of @_var would trample the @_var in Class#something
# (while both appeared to be class-local)
end
end

Of course this “trampling” happens now, with @var, but I think it
should be understood that it would not happen with @var. The @
variables, as I understand it, are distinct on a per-object, per-name,
per-class basis.

By the way, I still strongly dislike the @_ form, and would prefer
that all instance vars behave this way than that there be such a
prefix. (I don’t particularly advocate that, but it would be a lot
better than new punctuation strings.) If I’m counting correectly,
e’re actually going to outnumber Perl in variable prefixes: [@ @@ @_$]
vs. [$ @ %]. Well, OK, it’s a bit misleading to put it that way,
since Ruby’s local variables will always be nice and clean-looking :slight_smile:
But still.

David

···

On Fri, 5 Dec 2003, Christoph wrote:

–
David A. Black
dblack@wobblini.net

38

Hi,

···

In message “Re: Attempted roadmap of future instance variables…” on 03/12/05, “Christoph” chr_mail@gmx.net writes:

To give you another example of what I am trying to say lets say

class A
def initialize
@_test = “test”
end
def test
@_var
end
end

a = A.new

p a.test # “test”

class << a
def test
@_var
end
end

p a.test # nil or “test”

nil.

						matz.
39

By the way, I still strongly dislike the @_ form, and would prefer
that all instance vars behave this way than that there be such a
prefix.

Well, for me this is similar to the phrase at the end of the slide 13.

Change the way how work @var actually and you break a big number of
scripts (and I know that if you introduce @_var, you also break some
scripts)

Guy Decoux

40

I rather agree with you on disliking the @_ form, but perhaps for different
reasons. In my module Transaction::Simple, I have named most of the
variables in the pattern @foo (e.g., @checkpoint) so as to reduce
the chance of name collision. I’m not sure that I want magic behaviour
because of my choice to do this.

I’m not sure that I understand what the differing semantics between @ and @_
variables will be, either, despite having read this thread with interest.
What is the problem that @_ variables are trying to solve? (And what will
happen with the currently ugly but legitimate variable name “@_”?)

-austin

···

On Fri, 5 Dec 2003 22:56:41 +0900, David A. Black wrote:

By the way, I still strongly dislike the @_ form, and would prefer that
all instance vars behave this way than that there be such a prefix. (I
don’t particularly advocate that, but it would be a lot better than new
punctuation strings.) If I’m counting correectly, e’re actually going to
outnumber Perl in variable prefixes: [@ @@ @_$] vs. [$ @ %]. Well, OK,
it’s a bit misleading to put it that way, since Ruby’s local variables
will always be nice and clean-looking :slight_smile: But still.

–
austin ziegler * austin@halostatue.ca * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.12.05
* 11.22.51