Overriding class variables

ruby-talk
1

In ruby 1.6.8, overriding class variables cause weird (to me at least)
results:

class Foo
Const = 0

def c
Const
end
end

class Bar < Foo
Const = 1
end

print Bar.new.c

will print “0”. Apparently, since Bar.c really calls Foo.c, when it
looks up the class variable Const, it looks it up in Foo.
However, this seems odd to me – I expected the above code to print
"1".
Is it supposed to work this way (and if so, why?), or have I
discovered a bug in ruby?

Nathan

2

That’s not a class variable. You want @@const or something… although
a class variable isn’t a const. OTOH, you’re changing it, so you don’t
want a const, either. :wink:

Use @@var. It acts like you want.

···

On Sun, 11 May 2003 11:30:22 +0900 elbows@spamcop.net (Nathan Weston) wrote:

In ruby 1.6.8, overriding class variables cause weird (to me at least)
results:

class Foo
Const = 0

–
Ryan Pavlik rpav@users.sf.net

“This sand tastes like dirt…” - 8BT

3

Nathan Weston wrote:

In ruby 1.6.8, overriding class variables cause weird (to me at least)
results:

class Foo
Const = 0

def c
Const
end
end

class Bar < Foo
Const = 1
end

print Bar.new.c

will print “0”. Apparently, since Bar.c really calls Foo.c, when it
looks up the class variable Const, it looks it up in Foo.
However, this seems odd to me – I expected the above code to print
“1”.
Is it supposed to work this way (and if so, why?), or have I
discovered a bug in ruby?

I think this is because constants are scoped statically. One way to get
around that is to define Foo#c by:

def c
self.class::Const
end

This forces dynamic scope.

4

Ryan Pavlik wrote:

In ruby 1.6.8, overriding class variables cause weird (to me at least)
results:

class Foo
Const = 0

That’s not a class variable. You want @@const or something… although
a class variable isn’t a const. OTOH, you’re changing it, so you don’t
want a const, either. :wink:

Use @@var. It acts like you want.

Does it?

class Foo
@@Const = 0

 def c
   @@Const
 end

end

class Bar < Foo
@@Const = 1
end

print Bar.new.c # ==> 1

print Foo.new.c # ==> 1

That may or may not be what the OP wanted.

···

On Sun, 11 May 2003 11:30:22 +0900 > elbows@spamcop.net (Nathan Weston) wrote:

5

Ryan Pavlik rpav@nwlink.com wrote in message news:20030510194422.13279d29.rpav@nwlink.com…

In ruby 1.6.8, overriding class variables cause weird (to me at least)
results:

class Foo
Const = 0

That’s not a class variable. You want @@const or something… although
a class variable isn’t a const. OTOH, you’re changing it, so you don’t
want a const, either. :wink:

Use @@var. It acts like you want.

Oops, I forgot about @@var. However, that still doesn’t do what I
want. As another poster pointed out, changing @@var in the subclass
changes it for the superclasses. Which is even more weird – it means
the behavior of a class can be changed simply by defining a subclass
of it. If that is intentional, it seems like a rather odd design
choice.

Nathan

···

On Sun, 11 May 2003 11:30:22 +0900 > elbows@spamcop.net (Nathan Weston) wrote:

6

Joel VanderWerf vjoel@PATH.Berkeley.EDU wrote in message news:3EBDCC8F.6080208@path.berkeley.edu…

Nathan Weston wrote:

In ruby 1.6.8, overriding class variables cause weird (to me at least)
results:

class Foo
Const = 0

def c
Const
end
end

class Bar < Foo
Const = 1
end

print Bar.new.c

will print “0”. Apparently, since Bar.c really calls Foo.c, when it
looks up the class variable Const, it looks it up in Foo.
However, this seems odd to me – I expected the above code to print
“1”.
Is it supposed to work this way (and if so, why?), or have I
discovered a bug in ruby?

I think this is because constants are scoped statically. One way to get
around that is to define Foo#c by:

def c
self.class::Const
end

This forces dynamic scope.

Ah, that was exactly what I wanted. Thanks.

Nathan

7

Nathan Weston wrote:

Oops, I forgot about @@var. However, that still doesn’t do what I
want. As another poster pointed out, changing @@var in the subclass
changes it for the superclasses. Which is even more weird – it means
the behavior of a class can be changed simply by defining a subclass
of it. If that is intentional, it seems like a rather odd design
choice.

The whole point of class variables in most OO languages is to reveal
something common to all instances of the class, and that includes
instances of subclasses. I don’t see any horrible difference between
creating a subclass modifying such a class as opposed to an instance of
a subclass doing the same.

So PoLS as relates to most wide-spread OO languages isn’t what I’d label
an odd design choice :slight_smile:

···

–
([ Kent Dahl ]/)_ ~ [ http://www.stud.ntnu.no/~kentda/ ]/~
))_student/(( _d L b_/ NTNU - graduate engineering - 5. year )
( __õ|õ// ) )Industrial economics and technological management(
_/ö____/ (_engineering.discipline=Computer::Technology)

8

Ryan Pavlik rpav@nwlink.com wrote in message news:20030510194422.13279d29.rpav@nwlink.com…

Use @@var. It acts like you want.

Oops, I forgot about @@var. However, that still doesn’t do what I
want. As another poster pointed out, changing @@var in the subclass
changes it for the superclasses. Which is even more weird – it means
the behavior of a class can be changed simply by defining a subclass
of it. If that is intentional, it seems like a rather odd design
choice.

Hrm, oops, I misread your intentions in the original post.

Yes, I find this highly odd and annoying, but I guess it’s there for
something useful (even though I’m not sure what that something is ;).

Anyhow, what I’ve done is use @instance variables for the class,
which is like a static variable in other languages, in that it’s
unique to the given class but not subclasses. Accessors to this
are a quick addition if they’re necessary.

However, looks like you found what you wanted with the explicit
referencing of constants.

···

On Mon, 12 May 2003 03:14:33 +0900 elbows@spamcop.net (Nathan Weston) wrote:

–
Ryan Pavlik rpav@users.sf.net

“Darn that uncertainty principle! It always gets me lost.” - 8BT