On Mon, 12 Oct 2009, dreamcat four wrote:
Â Â end
It shouldn’t be mandated to re-invent the wheel in any programming
language, even if its fun style / fun to write. Here is why Robert:
because you would have just put 2 bugs into your code.
But using the available techniques in a language to put together
something higher level is not “re-inventing the wheel” (unless you do
it repeatedly). The language cannot be expected to incorporate an
abstract construct for every use case.
- It breaks when you want to set foo = nil in a subclass.
You can fix this with a defined? test.
- Not having an accessor definition will break other code.
That’s not broken; it just means that what Robert is doing isn’t
identical to what, say, attr_accessor does. You could modify Robert’s
code to assign to the instance variable the first time around rather
than just examining it, or something like that.
Most people would try / expect to fix by putting attr_accessor :foo at
top class A. It simply doesn’t work and the regular accessor is not
It is inherited; that is, given this:
class B < A
instances of B will have an x attribute. But, as you say, this isn’t
relevant to the class instance, and if people try to do it in order to
address class-level state, they just haven’t yet learned enough about
the Ruby object model to know that things don’t work that way. So
Because in Ruby the Class is instantiated as an instance of
object. You could probably imagine a little imaginary OO professor
(A class is actually an instance of Class.)
tugging at your clothes and saying ‘tut tut, such a shame’ or
something. And you might argue back that the point was that these
aren’t bugs if you understand the limitations etc, etc. Just like
being back at school eh? But i can assure you when any real programmer
in the real world comes along to use your classes and / or modify your
code, these holes are eventually surface as real breakages / bugs.
I don’t know whether Robert regards them as bugs or not, but I think
the main point is that there a whole world of this stuff you can do
trivially in Ruby. Besides, the examples we send back and forth on
ruby-talk aren’t necessarily fully field-tested; that’s not really the
point of the forum
to decide whether they would want to implement it, and/or how. I’m
very surprised no-one has asked for this on 1.9 line, or to change the
existing @@ behaviour since are changed the block level variable
scoping and many other things.
I’m still not seeing why it’s so important that it be addressed in the
core. Of course I’d be glad to see @@ changed to something more useful
(Robert and I have been among the most vocal critics of class
variables over the years but I don’t want to see classes
special-cased when it comes to how they maintain their own state.
They’re objects, and objects maintain state with instance variables,
which classes can easily do.
I’ve often said that “because classes are also objects” is the answer
to 75% of all questions about Ruby That’s actually why I don’t
like extra special cases for classes. Once people understand that
they’re objects, and let go of trying to view them as entirely
special, many things fall into place and the language makes more
The Ruby training with D. Black, G. Brown, J.McAnally
Compleat Jan 22-23, 2010, Tampa, FL
David A. Black/Ruby Power and Light, LLC (http://www.rubypal.com)