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

7

7stud --

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
 
J

Jason Roelofs

Note: parts of this message were removed by the gateway to make it a legal Usenet post.

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

mortee

7stud said:
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.

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
 
D

David A. Black

Hi --

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.

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

--
Upcoming training by David A. Black/Ruby Power and Light, LLC:
* Advancing With Rails, Edison, NJ, November 6-9
* Advancing With Rails, Berlin, Germany, November 19-22
* Intro to Rails, London, UK, December 3-6 (by Skills Matter)
See http://www.rubypal.com for details!
 
P

Phrogz

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

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.
 
D

David A. Black

Hi --

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.

I can't vouch for your sanity :) 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

--
Upcoming training by David A. Black/Ruby Power and Light, LLC:
* Advancing With Rails, Edison, NJ, November 6-9
* Advancing With Rails, Berlin, Germany, November 19-22
* Intro to Rails, London, UK, December 3-6 (by Skills Matter)
See http://www.rubypal.com for details!
 
7

7stud --

Thanks for the responses.
David A. Black wrote:
Hi --



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

7stud --

7stud said:
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'
 
D

David A. Black

Hi --

Thanks for the responses.


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".
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.

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

--
Upcoming training by David A. Black/Ruby Power and Light, LLC:
* Advancing With Rails, Edison, NJ, November 6-9
* Advancing With Rails, Berlin, Germany, November 19-22
* Intro to Rails, London, UK, December 3-6 (by Skills Matter)
See http://www.rubypal.com for details!
 
Y

Yossef Mendelssohn

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

7stud --

David said:
Hi --



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.



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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,733
Messages
2,569,440
Members
44,831
Latest member
HealthSmartketoReviews

Latest Threads

Top