From: Ned Konz <ned@...>
Date: 2001-07-24T06:28:37+09:00
Subject: [ruby-talk:18389] Re: More newbie questions

Matt wrote:

> OK. That worked! Now I'm confused (again) when to use the class and when
> to use an instance. For example take rfc1123_date. Why wasn't it inherited
> by the instance? I admit to not knowing enough about OO, but the only
> other language I've ever really tried was Perl's OO. And I hated it. ;)

Generally speaking, methods defined on the class are ones that don't deal 
with a specific instance of that class (object).

So for class methods, we see things like constructors (new etc.), utility 
methods (like the rfc1123_date you found), and methods that (for instance) 
keep track of objects of that class. These methods don't require an object. 
If a method doesn't call any object-side methods or deal with instance 
data, it should be on the class side. Or it should be an instance method in 
some other class (like, IMO, here).

Looking at CGI.rfc1123_date, it's apparently just a utility method that 
converts the output from time (a number) into a string with a particular 
format.

It would be meaningless to have put this in as an object method, since its 
behavior doesn't depend at all on _which_ cgi instance it's used with. In 
fact, it can be called even when there aren't any CGI objects in existence.

I would have probably put this in as an extension to the Time class as an 
object method. After all, if you have a Time, then you could ask it to give 
you its string representation in this format.

However, for some reason the author of the CGI class didn't do it this way, 
and just stuck what is basically a loose function into the class side. So 
you call it with the name of the class instead of on an object.

As an aside, this is how you'd go about writing non-OO programs in Ruby; by 
default (I think, I'm not yet a Ruby programmer) loose methods are stuck on 
the class side of Object.