'Class.inherited' v. 'inherited' syntax inside Class

Ruby
1

How come when you redefine the inherited method in Class, you don’t use
the ‘class method’ syntax? This doesn’t work:

class Class
def Class.inherited(class_obj)
puts class_obj
puts
end
end

Instead, you have to write:

class Class
def inherited(class_obj)
puts class_obj
puts

end
end

Yet, in pickaxe2 on p. 445, the book lists inherited as a class method
of Class. And, if I have a class like this:

class Dog
def Dog.speak
puts ‘Woof’
end
end

Dog.speak
–>Woof

and I want to redefine Dog.speak, I have to do this:

class Dog
def Dog.speak
puts ‘yap yap’
end
end

Dog.speak
–>yap yap

2

On Nov 8, 2007 3:27 PM, 7stud – [email protected] wrote:

Yet, in pickaxe2 on p. 445, the book lists inherited as a class method
–>Woof
Dog.speak
–>yap yap

Posted via http://www.ruby-forum.com/.

I would guess it’s because inheritance and everything related to it is
defined at object instantiation, not at Class definition. I would
believe
that the Ruby VM doesn’t care about class heirarchy until an object is
built, then it needs to look around to find out what’s available to this
new
object and what’s not. You can do

class Class
def Class.some_method
end
end

just fine, but this isn’t the problem you’re seeing. You’re seeing a
problem
as to when a certain method is called.

Though please someone correct me if what I’ve said is wrong, this is
just
educated guessing.

Jason

3

7stud – wrote:

Yet, in pickaxe2 on p. 445, the book lists inherited as a class method
of Class.

I’m not sure what pickaxe writes about this, but how would it be called
on the class that’s been inherited if it were a class method of Class?
Then you couldn’t redefine it on a per-class basis.

mortee

4

Hi –

On Fri, 9 Nov 2007, 7stud – wrote:

Yet, in pickaxe2 on p. 445, the book lists inherited as a class method
of Class.

The term “class method” can refer to either of two things: an instance
method of Class, or a singleton method of a given class. When you call
them, the technique is the same:

class Class
def an_instance_method
puts “I’m an instance method of Class”
end
end

class C
def a_singleton_method
puts “I’m a singleton method of C”
end
end

C.an_instance_method
C.a_singleton_method

So… when you do this:

class Class
def inherited …

you’re defining an instance method called “inherited”, and all
instances of Class – that is, all classes – will have that method.

When you define Class.inherited, you’re defining a singleton method on
Class. The only thing that would be affected by that would be if you
created a subclass of Class – but Ruby doesn’t permit that.

David

5

On Nov 8, 2007, at 6:32 PM, David A. Black wrote:

class C
def a_singleton_method
puts “I’m a singleton method of C”
end
end

I think David meant:

class C
def self.a_singleton_method # <— note self
puts “I’m a singleton method of C”
end
end

Gary W.

6

On Nov 8, 4:32 pm, “David A. Black” [email protected] wrote:

end

C.an_instance_method
C.a_singleton_method

O.o

David, I suggest that your example above is missing one of:
“self.”
“C.”
“class << self…end” wrapper

Right? Tell me I’m not insane.

7

Hi –

On Fri, 9 Nov 2007, Phrogz wrote:

 end

“class << self…end” wrapper

Right? Tell me I’m not insane.

I can’t vouch for your sanity :slight_smile: But you (and Gary) are totally
(W)right about my error. Thanks for pointing it out; it should indeed
be def C.a_singleton_method (at least, that’s the form I meant to use,
to mirror the def Class.inherited example).

David

8

Thanks for the responses.

David A. Black wrote:
Hi –

On Fri, 9 Nov 2007, 7stud – wrote:

Yet, in pickaxe2 on p. 445, the book lists inherited as a class method
of Class.

The term “class method” can refer to either of two things: an instance
method of Class, or a singleton method of a given class.

Wouldn’t it be more proper to call an instance method of Class a “Class
method” rather than a ‘class method’. In any case, I don’t think your
explanation applies to the page I referenced in pickaxe2. Every class
in the reference section starts with the class name a the beginning of a
section, and then the methods for the class are listed on the subsequent
pages. But the methods are divided into the categories: Class methods,
Instance methods, and Private methods. On p. 445, it says:

class Class < Module
…
…

Class methods:
inherited
…

new
…

Instance methods:
allocate
…

new
…

superclass
…

Based on your explanation, I think that is a clear case for the errata.
In fact, I checked ri, and ri produces this:

Class methods:

new

Instance methods:

 allocate, inherited, initialize_copy, new, superclass

(END)

When you call
them, the technique is the same:

class Class
def an_instance_method
puts “I’m an instance method of Class”
end
end

class C
def C.a_singleton_method
puts “I’m a singleton method of C”
end
end

C.an_instance_method
C.a_singleton_method

Ok, thanks. That explains why the inherit method in Class, when
overridden in a user defined class, must be defined using the ‘class
method’ syntax, e.g. UserClass.inherit. I thought the method in Class
was named Class.inherit (because pickaxe2 said so), and in order to
override that in a user defined class, you defined it with the same
syntax, e.g. MyClass.inherit.

So… when you do this:

class Class
def inherited …

you’re defining an instance method called “inherited”, and all
instances of Class – that is, all classes – will have that method.

When you define Class.inherited, you’re defining a singleton method on
Class. The only thing that would be affected by that would be if you
created a subclass of Class – but Ruby doesn’t permit that.

Ok. Thanks for clearing things up.

9

Hi –

On Fri, 9 Nov 2007, 7stud – wrote:

The term “class method” can refer to either of two things: an instance
method of Class, or a singleton method of a given class.

Wouldn’t it be more proper to call an instance method of Class a “Class
method” rather than a ‘class method’.

No, I don’t think that distinction is useful. You can certainly make
the distinction between instance methods of Class and singleton
methods of Class objects, but in practice, they’re both frequently
referred to as “class methods”.

…

new
…

superclass
…

Based on your explanation, I think that is a clear case for the errata.

I think the terminology gets a bit circular at the top of the tree.
inherited is (at least in 1.8.6) defined as a private instance method
of Class. My experience is that instance methods of Class or Module
are often referred to as “class methods”. For example, it’s common to
refer to attr_accessor as a class method. I don’t know whether that
was Dave’s thinking in listing it as a class method. It’s also a
slightly edge case since it doesn’t really do anything unless you
override it.

David

10

7stud – wrote:

Ok, thanks. That explains why the inherit method in Class, when
overridden in a user defined class, must be defined using the ‘class
method’ syntax, e.g. UserClass.inherit. I thought the method in Class
was named Class.inherit (because pickaxe2 said so), and in order to
override that in a user defined class, you defined it with the same
syntax, e.g. MyClass.inherit.

Whoops. ‘inherit’ --> ‘inherited’

11

On Nov 8, 5:32 pm, “David A. Black” [email protected] wrote:

When you define Class.inherited, you’re defining a singleton method on
Class. The only thing that would be affected by that would be if you
created a subclass of Class – but Ruby doesn’t permit that.

David

I did not know that. You learn something every day.

Of course, I’ve never considered doing so, which is obviously a good
part of why I didn’t know.

12

David A. Black wrote:

Hi –

On Fri, 9 Nov 2007, 7stud – wrote:

The term “class method” can refer to either of two things: an instance
method of Class, or a singleton method of a given class.

Wouldn’t it be more proper to call an instance method of Class a “Class
method” rather than a ‘class method’.

No, I don’t think that distinction is useful. You can certainly make
the distinction between instance methods of Class and singleton
methods of Class objects, but in practice, they’re both frequently
referred to as “class methods”.

Ok.

Based on your explanation, I think that is a clear case for the errata.

I think the terminology gets a bit circular at the top of the tree.

Yes, it’s quite confusing up there.

inherited is (at least in 1.8.6) defined as a private instance method
of Class.

Then I find the listing for Class in the pickaxe2 reference section
completely out of sync with the rest of the reference section, which
clearly makes distinctions between “Class methods”(with a capital ‘C’),
Instance methods, and Private Instance methods. My overriding thought
is: “you can’t have it both ways”. If you say all methods of Class are
‘class methods’, then in the listing for Class, all the methods should
be under one heading–not like this:

Class methods:
inherited
…

new
…

Instance methods:
allocate
…

new
…

superclass

To me, those categories say that allocate and inherited are different in
some way. According to your explanation, they are not. If you want to
say all methods in Class are ‘class methods’, then the listing should be
consistent with that thought, e.g.:

class methods(with a little ‘c’):
inherited
…

new
…

allocate
…

superclass
…

or more accurately(which would be my preference):

Private instance methods:
inherited
…

new
…

allocate
…

superclass
…

My experience is that instance methods of Class or Module
are often referred to as “class methods”.

Ok.

For example, it’s common to
refer to attr_accessor as a class method. I don’t know whether that
was Dave’s thinking in listing it as a class method. It’s also a
slightly edge case since it doesn’t really do anything unless you
override it.

Thanks for the explanation.