[lnkForumImage]
TotalShareware - Download Free Software

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


 

Forums >

comp.lang.ruby

Class is object? :very_sleepy

Alex Combas

1/26/2006 10:26:00 AM

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!

--
Alex Combas
http://noodlejunkie.blo...


6 Answers

Ross Bamford

1/26/2006 11:30:00 AM

0

On Thu, 2006-01-26 at 19:25 +0900, Alex Combas 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 :>

--
Ross Bamford - rosco@roscopeco.REMOVE.co.uk



Walter Prins

1/26/2006 11:38:00 AM

0

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



Alex Combas wrote:

>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!
>
>--
>Alex Combas
>http://noodlejunkie.blo...
>
>
>
>


Eivind Eklund

1/26/2006 3:07:00 PM

0

On 1/26/06, Alex Combas <alex.combas@gmail.com> 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.


dblack

1/26/2006 3:57:00 PM

0

Paul Brannan

1/26/2006 4:12:00 PM

0

Take a look at the output from "ri Class" some time (or see
http://ruby-doc.org/core/classes/...). It will either clear
things up or make them more confusing than ever before possible.

Paul




Lionel Thiry

1/26/2006 5:20:00 PM

0

> 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 Thiry

Personal web site: http://users.skynet....