Everyone talks so beautifully about “learn by doing”... well, I think just learn by doing is an EXTREMELY SLOW way. You have to really get your head into understanding how it works. Every programmer learns by doing, and most don't even understand the basic mechanics of how their programs work. That's why there are so many waves of methods of programming (agile, etc.). The reason people need that is a lack of properly understanding. Instead of learn by doing, I like LEARN BY THINKING A WHOLE FRIGGING LOT TILL YOU HAVE IT IN YOUR HEAD PERFECTLY CLEAR THE MECHANICS OF WHAT YOU'RE STUDYING.
at about minute 57, Dave says "The question was: Is this < some kind of method that is called on the class object? That would be so nice if it was, but it is not. It would be really cool because it would be possible o override inheritance" and people start laughing. But it's possible in the case of Smalltalk, it's possible to duck type inheritance change metaclasses behavior or creating new metaclasses. And Allan Key once said that this is a smalltalk feature that is underused.
Hey Aleksandar! How are you doing? Do you use ruby in your job? Или изучаваш нещо метапрограмирането? Уча в свободното време ... и се радвам се да те видя.
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.
+Kevin Finch Well, I found the answer and it is a subtlety that Dave's presentation elides. The trick to resolving class methods is explained in section '7.8.1 Class Method Lookup' of the first edition of 'The Ruby Programming Language'. In fact, in this section, the key to resolving to these class calls is referred to as a 'twist' on the regular method resolution that Dave outlines so well in the presentation. If you have this book, you are better off going to it and reading this section. If you don't, read on and I will do my best. So here is the twist. It turns out that eigenclasses have parents! My problem was that I did not understand how inherited class methods would be 'seen' by the resolution scheme as presented in the video. In fact they would not be, since Dave states that once a method is searched for in the eigenclass (and not resolved) the next step is to go to the object's class and start the search there. If that is the case, then no superclass methods would be seen. But the 'twist' is that eigenclasses have parents, which are the same as the parents of the underlying classes, and the next step in method resolution - instead of going to the Class methods for resolution - is to look at the methods in the eigenclass's parent eigenclass. This is fairly confusing, so here is an example. Let's say that we have a class A where we define a class method 'A_method'. We now define a new class B, inherited from A (that is, B is a subclass of A) and we define a class method on B named 'B_method'. Note that at this point we have created two eigenclasses, each with one method in them, associated with these two classes. Now we decide to use the 'A_method' by writing 'B.A_method'. What happens? Well, first we look into the eigenclass of class B. Of course, we don't find it there since only 'B_method' is sitting in that eigenclass. But now we come to the twist: the next step is to look at the parent of B's eigenclass, which is class A's eigenclass, and there we find 'A_method'. Problem solved. It is always helpful in doing technical presentations to give as much detail as needed to answer anticipated questions of some of the more curious audience members. Of course, it is tough to know where to draw that line and it is easy to criticize. Still, this is a key bit of information that is really needed to be understood in order to know how to resolve class methods.
Excellent question and example there! I thought I had this object model figured out until I read your question and made me rethink. After playing a while, it's just as you say.. If you take the "one to the right and up" you'll find that the B's class is it's metaclass, and that metaclass has A's metaclass for a parent. Then A's metaclass's parent is Object's eigenclass. One to the right and up solves all haha.
2021, and still incredibly clear and relevant. Beautiful
Simply brilliant and clarifies most of things.
Excellent, thank you!
Awesome video. This presentation is the perfect companion to the book "Metaprogramming Ruby".
Everyone talks so beautifully about “learn by doing”... well, I think just learn by doing is an EXTREMELY SLOW way. You have to really get your head into understanding how it works. Every programmer learns by doing, and most don't even understand the basic mechanics of how their programs work. That's why there are so many waves of methods of programming (agile, etc.). The reason people need that is a lack of properly understanding. Instead of learn by doing, I like LEARN BY THINKING A WHOLE FRIGGING LOT TILL YOU HAVE IT IN YOUR HEAD PERFECTLY CLEAR THE MECHANICS OF WHAT YOU'RE STUDYING.
What a lecture!
Amazing !! ... you save me hours and hours of reading and research and explain OOP in Ruby in a beautiful fun way. Thank you very much Dave !! (Y) ;)
I like this guy.
at about minute 57, Dave says "The question was: Is this < some kind of method that is called on the class object? That would be so nice if it was, but it is not. It would be really cool because it would be possible o override inheritance" and people start laughing. But it's possible in the case of Smalltalk, it's possible to duck type inheritance change metaclasses behavior or creating new metaclasses. And Allan Key once said that this is a smalltalk feature that is underused.
thx for the video
Hey Aleksandar! How are you doing? Do you use ruby in your job? Или изучаваш нещо метапрограмирането? Уча в свободното време ... и се радвам се да те видя.
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.
+Kevin Finch Well, I found the answer and it is a subtlety that Dave's presentation elides. The trick to resolving class methods is explained in section '7.8.1 Class Method Lookup' of the first edition of 'The Ruby Programming Language'. In fact, in this section, the key to resolving to these class calls is referred to as a 'twist' on the regular method resolution that Dave outlines so well in the presentation. If you have this book, you are better off going to it and reading this section. If you don't, read on and I will do my best.
So here is the twist. It turns out that eigenclasses have parents! My problem was that I did not understand how inherited class methods would be 'seen' by the resolution scheme as presented in the video. In fact they would not be, since Dave states that once a method is searched for in the eigenclass (and not resolved) the next step is to go to the object's class and start the search there. If that is the case, then no superclass methods would be seen. But the 'twist' is that eigenclasses have parents, which are the same as the parents of the underlying classes, and the next step in method resolution - instead of going to the Class methods for resolution - is to look at the methods in the eigenclass's parent eigenclass.
This is fairly confusing, so here is an example. Let's say that we have a class A where we define a class method 'A_method'. We now define a new class B, inherited from A (that is, B is a subclass of A) and we define a class method on B named 'B_method'. Note that at this point we have created two eigenclasses, each with one method in them, associated with these two classes.
Now we decide to use the 'A_method' by writing 'B.A_method'. What happens? Well, first we look into the eigenclass of class B. Of course, we don't find it there since only 'B_method' is sitting in that eigenclass. But now we come to the twist: the next step is to look at the parent of B's eigenclass, which is class A's eigenclass, and there we find 'A_method'. Problem solved.
It is always helpful in doing technical presentations to give as much detail as needed to answer anticipated questions of some of the more curious audience members. Of course, it is tough to know where to draw that line and it is easy to criticize. Still, this is a key bit of information that is really needed to be understood in order to know how to resolve class methods.
Excellent question and example there! I thought I had this object model figured out until I read your question and made me rethink. After playing a while, it's just as you say.. If you take the "one to the right and up" you'll find that the B's class is it's metaclass, and that metaclass has A's metaclass for a parent. Then A's metaclass's parent is Object's eigenclass. One to the right and up solves all haha.
Nice technical details. I failed to see the beauty though ;)
27:05
Shame on me
why??