class variable leading a double life

[Eric Mahurin]

Hi --
=20

Thanks for the example. I'm just wondering why

class Foo
def blah
@@cnt +=3D 1
end
end

couldn't have been a shortcut for [an optimization of]:

class Foo
class << self
attr_accessor :cnt
end
def blah
self.class.cnt +=3D 1
end
end

I agree. Class variables should just be a shortcut for
instance variables of an object's class. Having an independent
and slightly different class variable concept seems redundant,
confusing, and inconsistent.

You could just say that these should be equivalent:

@@x # self.class.instance_eval{@x}
@@x =3D y # self.class.instance_eval{@x=3Dy}

=20
That's a breakage of encapsulation, though. In its capacity
as "just
an object", a class should have the same "rights" as any
other object
-- specifically, the right to keep its instance variables to
itself.[/QUOTE]

I don't think this is too much different than how it is now -
any instance can directly modify common class variables of its
parent. But, it is another namespace...

I think I like Devin's idea better -- essentially:
=20
@@x # self.class.x
@@x =3D y # self.class.x =3D y
=20
though I would want the writing of the accessor methods to be
explicit
(rather than having the @@x reference cause a singleton
method to be
written on the class).

I think I like this better too. You could even say
@@superclass to get an easy shortcut to an objects superclass.

Another idea would be to have the parser allow you to call the
"class" method directly rather than have to put the "self." in
there. Or just rename/alias "class" to something else - klass.
"klass.x" wouldn't be too much longer than "@@x".



=09
____________________________________________________=20
Yahoo! Sports=20
Rekindle the Rivalries. Sign up for Fantasy Football=20
http://football.fantasysports.yahoo.com