27:05

2021, and still incredibly clear and relevant. Beautiful

What a lecture!

I like this guy.

Awesome video. This presentation is the perfect companion to the book "Metaprogramming Ruby".

I am a Ruby newbie, with most of my experience in Java. I find this video informative but it still leaves me with a bit of confusion as to the distinction between instance methods and class methods. It seems that Dave goes to great pains to try to erase this distinction by saying something along the lines of 'there are no static (i.e. class) methods, everything is an object method: in order to resolve a method call you just look up the class of the object and then access that classes methods by going to the right (and then up the class hierarchy until you find the method if not found at the lower levels)'.

So the way that I interpret this statement is that object method calls (a method on an object of Class BottomClass) and class method calls (a method of class BottomClass itself) are essentially resolved in the same way. That is, to use Dave’s class diagram at minute 40:43, you would resolve an object call by looking at that object’s class (the value of the class field in the box on the left of the diagram) and then go one column right to find the method in that class (the bottom box in the central column). And if you don’t find the method there you would go up the hierarchy chain to find it. Simple enough: I think I understand that.

Similarly, to resolve an invocation of a class method you would go to that class’ class ‘property’ (for lack of a better word) and simply search that class’ methods. And if your method is not found there, you go up the inheritance tree searching for the right method, just as you would to resolve an instance method.

This explanation left with me with the overall impression that all methods are essentially equivalent (that is, instance methods and class methods have no definitional difference) and the question of whether to invoke one method or the other depended solely on where you start your search for the method (or, to use Dave’s terminology, on what ‘self’ was at the time of invocation). Getting back to Dave’s diagram, in the case of resolving an instance method you would start at the leftmost box and in the case of a ‘class method’ you would start at the center bottom box.

Suppose we have a class Foo and let’s further suppose that we define some ‘class method’ on Foo called ‘::someClassMethod’. Since we defined a class method on Foo, Ruby creates an eigenclass (or singleton class or whatever we want to call it) and the class property of class Foo points to this eigenclass. In other words, in Dave’s diagram the ‘class’ field of the bottom box in the middle column (our class Foo) would hold the (internally generated) name of this eigenclass. The eigenclass itself has Class as its parent and so on up the class hierarchy. This is the way that I understand the rightmost column of classes on Dave’s diagram.

So at long last I come to my point of confusion. To wit, the methods that you are looking for as you go up the rightmost hierarchy stack in trying to resolve a class method invocation are not the same methods that you are looking for (or ‘through’) as you go up the middle stack when resolving an instance method. In the case of Foo.new.someObjectMethod (which is an object method invocation) you are only looking at instance methods of your class and its parents. In the case of Foo::someClassMethod you are only looking at class methods of that class and its parents. So it seems to me that there is still a very real distinction between instance and class methods in a given class. And since I understood Dave to say that this distinction goes away upon understanding the way that the object model works, I remain confused.

If anyone can point out my conceptual error(s) here I would be most grateful. As I say, this is all new to me. Thanks for reading this far and apologies for the long posting. If I ever figure this out myself I will add an addendum explaining the error in my thinking. Thanks.

It's amazing how elegant is the design of the Ruby language. Couple of right design decisions made it so flexible and made metaprogramming quite easy to use in everyday life. I rewatch this video every year or so and it has all the key points you need to know about ruby metaprogramming. If you are already familiar with the subject it's a great overview video.

ps. For more gentle introduction to metaprogramming however, I recommend this video course to my collegues http://bit.ly/1BFhzf4

Nice technical details. I failed to see the beauty though 😉