[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: Class variables and Constants

Tony Mobily

2/20/2006 10:34:00 AM

Dear Tony,

[OK, I am gonna answer myself]

The main difference actually makes a lot of sense.

If you change a class constant (which you shouldn't do), then all of
the classes which inherited from it will see their constant changed
as well.

Class variables, on the other hand, are allocated for the class
itself. This means that each class (or sub-class) will have its own
class variables.

Here is some code to clarify the concept.

-----------------------------------------------
#!/usr/local/bin/ruby -w

class TonyCantCode
@@internal=10

def TonyCantCode::something
return @@internal
end

def TonyCantCode::something=(what)
@@internal=what
end


end

class TonyReallyCantCode
Something=20
end

class TonyCantCode2 < TonyCantCode
end

class TonyReallyCantCode2 < TonyReallyCantCode
Something=20
end


p TonyCantCode::something
p TonyReallyCantCode::Something

TonyCantCode::something=30
TonyReallyCantCode::Something=40

p TonyCantCode::something
p TonyReallyCantCode::Something

p TonyCantCode2::something
p TonyReallyCantCode2::Something


RESULT:

$ ./vars.rb
10
20
/vars.rb:33: warning: already initialized constant Something
30
40
30
20 <-- !!!

---------------------------------------------------

Bye!

Merc.



On 20/02/2006, at 6:05 PM, Tony Mobily wrote:

> Hello people,
>
> what is the actual difference between class variables and constants?
>
> If I write:
>
> ------------------------------------------
> #!/usr/local/bin/ruby -w
>
> class TonyCantCode
> @@internal=10
>
> def TonyCantCode::something
> return @@internal
> end
>
> def TonyCantCode::something=(what)
> @@internal=what
> end
>
>
> end
>
> class TonyReallyCantCode
> Something=20
> end
>
> p TonyCantCode::something
> p TonyReallyCantCode::Something
>
> TonyCantCode::something=30
> TonyReallyCantCode::Something=40
>
> p TonyCantCode::something
> p TonyReallyCantCode::Something
> ------------------------------------------------
>
> I get a warning about changing a constant, PLUS I called the method
> TonyCantCode::something so that I didn't have to use the brackets
> at the end.
>
> BUT... as far the the scope is concerned, they do seem to be very.
> very similar.
> As far as I can see:
>
> * Constants would be referenced mainly from the OUTSIDE of the
> class. For example, if TonyReallycantCode::Something was something
> very meaningful to the USERS of TonyReallyCantCode.
>
> * Class variables would be used mainly from WITHIN the class. Yes,
> it is possible to create accessors, but they might not be necessary.
>
> This is what I worked out. Now the question is: is all the above
> correct?
>
> BYE!
>
> Merc.


5 Answers

dblack

2/20/2006 12:35:00 PM

0

Tony Mobily

2/20/2006 1:41:00 PM

0

Hi,


> Have you tried this?
>
> class A
> @@var = 10
> def self.var
> @@var
> end
> end
>
> class B < A
> @@var = 20
> end
>
> p A.var
>
> :-)

AAAAAAAHHHHHHHHH!!!!!!!!!!!!
I've been playing with this the whole night. I am not gonna stop
until I've finished writing a clear document that explains absolutely
everything.

Merc.



Tony Mobily

2/20/2006 2:18:00 PM

0

Hi,

>> AAAAAAAHHHHHHHHH!!!!!!!!!!!!
>> I've been playing with this the whole night. I am not gonna stop
>> until I've finished writing a clear document that explains
>> absolutely everything.
> I think Matz is planning to change class variables in 2.0 so that they
> are class/module scoped rather than hierarchy scoped. Meanwhile,
> here's another fun variant:
>
> class A
> end
>
> class B < A
> @@var = 10
> def self.var
> @@var
> end
> end
>
> class A
> @@var = 20
> def self.var
> @@var
> end
> end
>
> p A.var
> p B.var

The result is:

20
10

Oh dear... let me guess.
To start with, the class A doesn't have @@var defined. Class B is
defined, and @@var is allocated. B will share @@var with all of its
children. Then, A happened to be extended and @@var is allocated. It
will share @@var with its children, but NOT B.
The compiler smells something fishy there, and says:

/p.rb:9: warning: class variable @@var of A is overridden by B

Which is what happens: effectively, the hierarchy rule is NOT going
to be satisfied.

I love Ruby, but this is so error-prone it's not funny :-|

Merc.


David Vallner

2/21/2006 2:36:00 AM

0

Dna Pondelok 20 Február 2006 14:50 dblack@wobblini.net napísal:
> > AAAAAAAHHHHHHHHH!!!!!!!!!!!!
> > I've been playing with this the whole night. I am not gonna stop until
> > I've finished writing a clear document that explains absolutely
> > everything.
>

I tried to do Poor Man's Traits in Java using static fields. I feel your pain.

It's especially likely to cause initialization timing bugs - when I loaded the
page from the webapp after a server restart, everything worked fine - by some
strange coinkydink, the classes loaded earlier weren't used after they got
clobbered by the subclasses loaded earlier. Lossage ensued after a page
reload.

> I think Matz is planning to change class variables in 2.0 so that they
> are class/module scoped rather than hierarchy scoped. Meanwhile,
> here's another fun variant:
>
> class A
> end
>
> class B < A
> @@var = 10
> def self.var
> @@var
> end
> end
>
> class A
> @@var = 20
> def self.var
> @@var
> end
> end
>
> p A.var
> p B.var
>

Oh dear. I do hope the change gets into 2.0, I can't wait for Java trolls to
ramble against it...

(Now don't tell anyone, but I have a hunch class instance variables actually
work like you'd expect in this case. I think.)

David Vallner


dblack

2/21/2006 2:48:00 AM

0