MudBytes
» MUDBytes Community » Language Discussions » Ruby » class variables
Pages: << prev 1, 2, 3, 4 next >>
class variables
Runter
Wizard






Group: Members
Posts: 1,850
Joined: Jun 1, 2006

Go to the bottom of the page Go to the top of the page
#46 id:43875 Posted Mar 15, 2010, 3:52 pm

flumpy said:

Runter said:
flumpy said:
Ah, but if I'd overridden new in any object, you wouldn't expect different behaviour either, no? The difference would be if I mentioned the behaviour in the docs, which then becomes reasonable and fair.

No other point really, either :D


Well, yeah, but I wouldn't expect you to be able to override the way class variables behave on principle unless you changed the C core.


Why not? What about for unit testing purposes? Am I missing something, or is't new a method call on the Class object? If so, it seems reasonable that you should be able to override/change it's functionality just like any other object...

Perhaps I am getting it wrong if you think that is one behaviour that should not change.. I don't know Ruby too well after all.


The discussion has been about how internally class variables are stored and language/syntax macros on how it is exposed to the user.  I wouldn't expect you to be able to override inside of Ruby the way class variables are stored [at the lowest level], no.  And also, it's probably intentional and shouldn't be changed.  It should, however, be more well documented.
.........................
CoralMud project

For once you have tasted flight Ruby you will walk the earth with your eyes turned skywards,
for there you have been and there you will long to return. --
                                              Leonardo Da Vinci Yukihiro Matsumoto

Last edited Mar 15, 2010, 3:53 pm by Runter
Tyche
Wizard






Group: Members
Posts: 1,343
Joined: May 23, 2006

Go to the bottom of the page Go to the top of the page
#47 id:43897 Posted Mar 15, 2010, 5:38 pm

Changing the example around...
Code (ruby):
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
 
class A
  def A.set a
    @@a = a
  end
  def A.get
    @@a
  end
end
class B
  def B.set a
    @@a = a
  end
  def B.get
    @@a
  end
end
 
B.set 1
p B.get
A.set 2
p A.get
p B.get
 


$ ruby classvar.rb
1
2
1

The only way to get unique class variables into your classes is to make certain you execute a reference to them at the lowest class in the inheritance chain first.  It's like @@somevar automatically generates read/write accessor methods, or more accurately is very much like a global $globalvar with scope in the class heirarchy.  Or as DavidHaley suggested they are automatically search for like method definitions.

That's why when a reference to @@a is executed a search for some @@a is conducted in the inheritance heirarchy and if not found is created in the context of the class that first referenced @@a.

Code (ruby):
1
2
3
4
5
6
7
8
9
10
 
class A
 @@a = 1   # executed when class is read
 def self.set x
  @@a = 2  # executed when A.set is executed
 end
end
 


So my first example
A.set 1
B.set 2

produces a class object scheme where the @@a ends up on the instances of only A
Code (text):
1
2
3
4
5
6
 
   B-------A
            @@a
 

The second example
B.set 1
A.set 2

produces a class object scheme where the @@a ends up on both instances
Code (text):
1
2
3
4
5
6
 
   B-------A
     @@a    @@a
 




.........................
http://jlsysinc.gotdns.com/ladybug_laugh2.jpghttp://jlsysinc.gotdns.com/teensymud_250x80.pnghttp://jlsysinc.gotdns.com/palin_calendar.jpg
For now we see through a glass, darkly; but then face to face: now I know in part; but then shall I know even as also I am known.


Last edited Mar 15, 2010, 5:39 pm by Tyche
David Haley
Wizard






Group: Members
Posts: 6,874
Joined: Jun 30, 2007

Go to the bottom of the page Go to the top of the page
#48 id:43899 Posted Mar 15, 2010, 5:44 pm

That's very interesting. It confirms that it's basically searching up the instance/method tree (or whatever it is: you've got to account for mix-ins and other fun things too).

It reminds me of pure prototype inheritance, like what you might see in Self, Javascript, or Lua tables/metatables. There's a strict ordering for where one finds things: first check the thing, then check its parent things (superclasses, prototypes, whatever you want to call them) in whatever order is defined by the language (depending on things like multiple inheritance, mix-ins, etc.).

Thanks for confirming it, it makes me feel better about what's going on here.
.........................
-- d.c.h --
BabbleMUD Project (custom codebase)
Legends of the Darkstone (head coder)
http://david.the-haleys.org
.........................

Pages:<< prev 1, 2, 3, 4 next >>
Tags
[+]

Valid XHTML 1.1! Valid CSS!