# Class is object? :very\_sleepy **URL:** \ **Category:** Ruby\ **Created:** [January 26, 2006, 11:27am UTC](https://www.ruby-forum.com/t/class-is-object-very-sleepy/97506 "2006-01-26T11:27:48Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![combas](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/aca169/32.png) [@combas](https://www.ruby-forum.com/u/combas)\ **Post date:** [January 26, 2006, 11:27am UTC](https://www.ruby-forum.com/t/class-is-object-very-sleepy/97506/1 "2006-01-26T11:27:48Z")
Was just thinking today, earlier, but at the moment I’m not reallly thinking, I’m mostly asleep right now, so probably shouldnt be writing, let alone typing, and especially not with this much Nightquil chugging though me… BUT OK!! TITLE: Class are objects!?! Here is my question: Does having class variables (@@) and class methods (MyClass.foo) destroy the whole OO design concept? I’ve always thought of classes like blueprints, and objects like, well, objects made from the blueprints. So thinking of classes as objects themselves that have :attributes, @@variables, and def methods kind of wrecks my “blueprint” metaphore. I know I’m wrong, I probably should have wrote that at the top in big green letters. I just want to throw this out and see just how many ways I can be proven wrong so that I can learn and maybe one of the ways will stick like a wet noodle on the wall of my brain for long enough that I dont have to ask this question again next week. What I would really like is a better metaphore for class! Thanks! ---
**Author:** ![combas](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/aca169/32.png) [@combas](https://www.ruby-forum.com/u/combas)\ **Post date:** [January 26, 2006, 12:31pm UTC](https://www.ruby-forum.com/t/class-is-object-very-sleepy/97506/2 "2006-01-26T12:31:06Z")
On Thu, 2006-01-26 at 19:25 +0900, Alex C. wrote: > Here is my question: Does having class variables (@@) and > class methods (MyClass.foo) destroy the whole OO design concept? > I’ve always thought of classes like blueprints, and objects like, well, objects > made from the blueprints. So thinking of classes as objects themselves > that have :attributes, @@variables, and def methods kind of wrecks > my “blueprint” metaphore. In your terms I’d probably say that Classes are Objects that represent a blueprint for other Objects. All Objects, including Classes, are built from a Class blueprint. All Objects, including Classes, can have additional capabilities added to their blueprint, and can get new capabilities custom made after they leave the factory, too. And I’d ignore @@vars, what I’ve seen so far suggests it’s the best thing to do most of the time :\> ---
**Author:** ![combas](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/aca169/32.png) [@combas](https://www.ruby-forum.com/u/combas)\ **Post date:** [January 26, 2006, 12:40pm UTC](https://www.ruby-forum.com/t/class-is-object-very-sleepy/97506/3 "2006-01-26T12:40:12Z")
consider a class as a “blueprint object”… problem solved. Remember, in OO “everything” is an object. But just because everything is an object, does not mean they’re the _same_ (or even similar.) A class is rather different to instances of classes (which we call objects with a slightly different emphasis) for sure, but if you step away far enough you can still call them _both_ objects in a more general sense. So “a class” is-a “object”, but in a more general sense. You can make the same argument about methods and many other things. To me it’s a subtle shift of perspective, and indeed _more_ OO than languages where you _don’t_ have the notion of treating most things as an object… My £0.02 anyway ---
**Author:** ![combas](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/aca169/32.png) [@combas](https://www.ruby-forum.com/u/combas)\ **Post date:** [January 26, 2006, 2:43pm UTC](https://www.ruby-forum.com/t/class-is-object-very-sleepy/97506/4 "2006-01-26T14:43:57Z")
On Jan 26, 2006, at 5:25 AM, Alex C. wrote: > I’ve always thought of classes like blueprints, and objects like, > well, objects > made from the blueprints. So thinking of classes as objects themselves > that have :attributes, @@variables, and def methods kind of wrecks > my “blueprint” metaphore. Just expand your model a bit. Think of classes as factories that build objects according to some blueprint. Every now and then the factory shuts down to be re-tooled. The machines are updated, the blueprint is altered, then the factory reopens and produces a slightly different object and, as a bonus, all the previously manufactured objects are magically upgraded to the new version also. Gary W. ---
**Author:** ![combas](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/aca169/32.png) [@combas](https://www.ruby-forum.com/u/combas)\ **Post date:** [January 26, 2006, 4:08pm UTC](https://www.ruby-forum.com/t/class-is-object-very-sleepy/97506/5 "2006-01-26T16:08:45Z")
On 1/26/06, Alex C. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > I know I’m wrong, I probably should have wrote that at the top in > big green letters. I just want to throw this out and see just how many > ways I can be proven wrong so that I can learn and maybe > one of the ways will stick like a wet noodle on the wall of my brain > for long enough that I dont have to ask this question again next week. > > What I would really like is a better metaphore for class! A better metaphor for a class is - a class! More seriously, I believe it’s a good idea to start thinking about classes as just classes as soon as possible. Or to go even further and think of classes as “Ruby classes”, “Perl classes”, etc. Metaphors are good for the initial communication, to create the new structures in your mind by copying aspects of old ones. As you’ve discovered, they’re treacherous when it comes to thinking about those things, though. They limit your thinking to just one dimension of the subject. Apart from that, the object factory pattern (as described in the thread and in the Gang of Four book) is one way to think of classes in Ruby. Another way to think of classes is to remember ways to implement them, underneath. A constructor just allocate some memory for an object, add in a pointer to the set of methods in the class and the class name, and call the initialize method on the “empty” object. Every time a method call is done on that object, the Ruby interpreter search through the list of classes that that object is involved with, in a prioritized order, and find the implementation to call. That implementation will be method\_missing if nothing else is found. None of these are “complete” per se. It’s still best to just remember that Ruby classes _are_ Ruby classes, and should be thought of as Ruby classes. That way, you’ll never go wrong - you just may learn more abour Ruby classes… Eivind. ---
**Author:** ![combas](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/aca169/32.png) [@combas](https://www.ruby-forum.com/u/combas)\ **Post date:** [January 26, 2006, 5:00pm UTC](https://www.ruby-forum.com/t/class-is-object-very-sleepy/97506/6 "2006-01-26T17:00:18Z")
Hi – On Thu, 26 Jan 2006, Alex C. wrote: > made from the blueprints. So thinking of classes as objects themselves > that have :attributes, @@variables, and def methods kind of wrecks > my “blueprint” metaphore. I agree with Ross that class variables are best avoided, though one does need to recognize them of course. In my view they cut a weird path across what would otherwise be very clear scoping rules. As for classes as objects: one way to think of it is that classes have both a kind of “official” status and a kind of “civilian” status. Sort of the way both parents and their children all have Social Security numbers (in the US, that is), even though in their parent/child relationship they play different roles from each other. Or the way everyone is really at the same level when it comes to medical needs, whatever else they do in society. Classes have a special role in Ruby “society”: they are responsible for bootstrapping other objects into existence. But they are also members of that society (i.e., objects themselves); so they can receive messages, own their own instance variables, etc. If you ignore class variables (which I try to 🙂 classes are actually special-cased in rather few ways. David – David A. Black removed\_email\_address@domain.invalid “Ruby for Rails”, from Manning Publications, coming May 1, 2006! > **[Ruby for Rails](https://www.manning.com/books/ruby-for-rails)** > > NEWER EDITION AVAILABLE > > The Well-Grounded Rubyist, Second Edition is now available. An eBook of the previous edition, The Well-Grounded Rubyist is included at no additional cost when you buy the revised edition! > > > Ruby for Rails helps Rails... ---
**Author:** ![combas](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/aca169/32.png) [@combas](https://www.ruby-forum.com/u/combas)\ **Post date:** [January 26, 2006, 6:24pm UTC](https://www.ruby-forum.com/t/class-is-object-very-sleepy/97506/7 "2006-01-26T18:24:56Z")
> What I would really like is a better metaphore for class! > Thanks! Objects generally don’t like to hold their methods themselves, that’s why they ask for other objects, called classes, to hold them. Those objects are smart and they gather the burden of methods with other objects, some of them are called modules, while the others are classes. Sometimes, an object like to hold a method without help. It wants to do it itself, alone, as if it was a singleton, the unique object of its kind in the universe. That’s why those kind of methods are called “singleton methods”. In ruby, even singleton methods are not truly hold by the object itself, even if all goes as if it was. A singleton method is hold by a special object whose name is still hard to define (singleton class, eigenclass, metaclass, etc…). – Lionel T. Personal web site: [http://users.skynet.be/lthiry/](http://users.skynet.be/lthiry/) ---
**Author:** ![combas](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/aca169/32.png) [@combas](https://www.ruby-forum.com/u/combas)\ **Post date:** [January 26, 2006, 5:12pm UTC](https://www.ruby-forum.com/t/class-is-object-very-sleepy/97506/8 "2006-01-26T17:12:26Z")
Take a look at the output from “ri Class” some time (or see [class Class - RDoc Documentation](http://ruby-doc.org/core/classes/Class.html)). It will either clear things up or make them more confusing than ever before possible. Paul ---
**Author:** ![combas](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/aca169/32.png) [@combas](https://www.ruby-forum.com/u/combas)\ **Post date:** [January 26, 2006, 6:37pm UTC](https://www.ruby-forum.com/t/class-is-object-very-sleepy/97506/9 "2006-01-26T18:37:03Z")
Hi – On Fri, 27 Jan 2006, Lionel T. wrote: > kind in the universe. That’s why those kind of methods are called > “singleton methods”. > > In ruby, even singleton methods are not truly hold by the object itself, > even if all goes as if it was. A singleton method is hold by a special > object whose name is still hard to define (singleton class, eigenclass, > metaclass, etc…). (Singleton class was the last term I heard Matz say he was using 🙂 The point about objects not holding methods is so important. People sometimes talk about “adding methods to objects”, and then get tripped up about method lookup order. It’s more a matter of the object meandering through classes and modules, in a certain order, trying to find a match for a message it’s received. David – David A. Black removed\_email\_address@domain.invalid “Ruby for Rails”, from Manning Publications, coming May 1, 2006! > **[Ruby for Rails](https://www.manning.com/books/ruby-for-rails)** > > NEWER EDITION AVAILABLE > > The Well-Grounded Rubyist, Second Edition is now available. An eBook of the previous edition, The Well-Grounded Rubyist is included at no additional cost when you buy the revised edition! > > > Ruby for Rails helps Rails...