Forum: Ruby Class is object? :very_sleepy

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Alex C. (Guest)
on 2006-01-26 12:27
(Received via mailing list)
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!
Ross B. (Guest)
on 2006-01-26 13:31
(Received via mailing list)
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 :>
Walter Prins (Guest)
on 2006-01-26 13:40
(Received via mailing list)
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
unknown (Guest)
on 2006-01-26 15:43
(Received via mailing list)
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.
Eivind E. (Guest)
on 2006-01-26 17:08
(Received via mailing list)
On 1/26/06, Alex C. <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.
unknown (Guest)
on 2006-01-26 18:00
(Received via mailing list)
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!
http://www.manning.com/books/black
Paul B. (Guest)
on 2006-01-26 18:12
(Received via mailing list)
Take a look at the output from "ri Class" some time (or see
http://ruby-doc.org/core/classes/Class.html).  It will either clear
things up or make them more confusing than ever before possible.

Paul
Lionel T. (Guest)
on 2006-01-26 19:24
(Received via mailing list)
> 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/
unknown (Guest)
on 2006-01-26 19:37
(Received via mailing list)
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!
http://www.manning.com/books/black
This topic is locked and can not be replied to.