method_added hook and class methods

[Keith Rarick]

Hello all, I am puzzled at some behavior I recently observed in ruby. I
searched the archives and google and didn't see an answer, so I am
asking here:

First I want to observe when instance methods are defined in a class, so
I do this:

class C
class << self
def method_added(name)
puts 'added ' + name.to_s
end
end

def an_instance_method
end
end

As I expect, this program prints "added an_instance_method".

Now I want to observe when class methods are defined. My understanding
of ruby says that "class methods" are really just instance methods of
the metaclass. So I do this:

class C
class << self
class << self
def method_added(name)
puts 'added ' + name.to_s
end
end

def a_class_method
end
end
end

I expect this program to print "added a_class_method", but it produces
no output.

Am I misunderstanding something or is this a bug?

Is there some other way to observe when class methods are defined?

Any help would be very much appreciated.

kr

 

[Nobuyoshi Nakada]

Hi,

At Fri, 3 Aug 2007 15:29:06 +0900,
Keith Rarick wrote in [ruby-talk:263159]:

Now I want to observe when class methods are defined. My understanding
of ruby says that "class methods" are really just instance methods of
the metaclass. So I do this:

class C
class << self

def singleton_method_added(name)
puts 'added ' + name.to_s
end

 

[Keith Rarick]

Hi,

At Fri, 3 Aug 2007 15:29:06 +0900,
Keith Rarick wrote in [ruby-talk:263159]:

Now I want to observe when class methods are defined. My understanding
of ruby says that "class methods" are really just instance methods of
the metaclass. So I do this:

class C
class << self

def singleton_method_added(name)
puts 'added ' + name.to_s
end

Thanks very much! This works perfectly.

Out of curiosity, why are metaclasses treated differently than regular
classes in this respect?

Suppose I am given a variable, x, that contains a class. The object may
be either a class or a metaclass, and I wish to observe the creation of
instance methods on x. Now I must do one of two different things
depending on the type of x (class or metaclass). (For the sake of
brevity, I assume a metaclass() method and ignore the fact that
define_method() is private.)

If x is a regular class:

x.metaclass.define_methodmethod_added) { |name| puts "added #{name}" }

or, if x is a metaclass:

x.define_methodsingleton_method_added) { |name| puts "added #{name}" }

Further, I do not know of a reliable way to determine if x is a regular
class or a metaclass, so I must actually do *both* if I want to be sure
to see the addition of a method on x.

Is this an accurate description or am I missing something?

kr

 

[Pit Capitain]

Out of curiosity, why are metaclasses treated differently than regular
classes in this respect?

Keith, I've been asking this time and again since a couple of years
ago. I think the reason is that Matz didn't want singleton classes to
be part of the Ruby language (yet). He always said it would be
possible to implement singleton methods without having singleton
classes. I got the impression that he might be changing his mind for
future versions of Ruby, though, but I'm not sure. Matz, if you read
this, are there some new insights concerning this topic?

Regards,
Pit

 

[Robert Dober]

Keith, I've been asking this time and again since a couple of years
ago. I think the reason is that Matz didn't want singleton classes to
be part of the Ruby language (yet).

A more recent thread about a Singleton class not being in ancestors
seems to confirm your theory.
Matz explicitly added a check for singleton classes not to be in
ancestor, he was kind of violating smooth flow. I was sure that he had
a hidden agenda in order to do such things, it might be what you said
below.
I nevertheless share the feelings of some others that it is a shame!
Of course if Matz were right I'd love to see the concept and I'd love
to see singleton classes go away, but I feel it is impossible .

He always said it would be
possible to implement singleton methods without having singleton
classes. I got the impression that he might be changing his mind for
future versions of Ruby, though, but I'm not sure. Matz, if you read
this, are there some new insights concerning this topic? +222 here

Regards,
Pit

Cheers
Robert