[MUSIC] In this segment let me show you Ruby's Mixins. These are a nice alternative to multiple inheritance. And are very similar to what are called traits in some other programming languages. So what is a Mixin? It is a collection of methods and only a collection of methods, so it's not a class. You can't instantiate it. You can't call new on it to get an instance of a Mixin. It is just a bunch of method definitions. Now, what do you do with a Mixin? Well languages, typically let you, in a class definition include as many mixins as you want. You can still have a super class. You still inherit those methods. Then you can also include Mixins and you get all of their methods, too. It is like you typed out the same method definitions. By including the Mixin, you avoid that copy and paste. So, it it really is just adding method definitions to some class when you include the Mixin. That way, you can extend your class definition with those methods. You can by including a Mixin override a method that was typed into a superclass and so on. So, this is really quite powerful. And the key reason we're going to see is, those Mixin methods that you include in your class can use self. They're so much part of the class definition that they can call other methods that you define in your class. That's going to be the key power we see. So, I'm going to show you a simple example first. We'll get to the cooler stuff in a bit, so it turns out in Ruby, we'll use this module keyword to define a Mixin. Module is also support name space management, so it's getting two different things. But here, I'm just going called them Mixins,because that's what they were using them for. So, here's a Mixin I'm calling Doubler. It happens to just have one method to find it. We could define as many methods as we want and this method is called Double. And when you call this method, it send self the plus message with self as an argument. So in this mixing, we are not defining plus. We are only defining double. We are assuming that any class that includes us will have plus define and we will call the plus method. So what we could do is, define a class like you see here, Point. Define the plus message, which just takes the x coordinate and the y coordinate and adds them together. Then, by including Doubler, so you just write keyword include and the Mixin you want to include. This class now has a double method and when you call it, that method will call the plus method. So, I've already loaded everything up over here. In fact, I've already even defined the point that I just previously created. And set the x corner to three and y corner to four. And now, it has a plus method, so I could say p plus. Well, I guess p is the only point I have, but I don't have to it that way, it also a double method. And you see as a result here that x is returning a new point where x is six and y is eoght. And of course, that point also has a double method and so on and this works great. So, we successfully did it. Now, you may have seen here over in the code that I also went and added, the doubler Mixin to the class string. Now, this is questionable style, going and changing an existing class. But it does work and indeed, if I come over here and I type "hello".double. It now has that method. All its doing is, calling the plus method on strings with hello itself and since plus concatenates, we get hello hello back. So you can do this, you can include as many Mixins as you want. Mixins can have as many methods as you want and this all works great, so we do have to be a little careful here. I was so careful to precisely define method look-up. Now that we have other ways to add methods to classes. It turns out Ruby has to have written out a bunch of rules on how you look up a method m. What if multiple Mixins define the method? What if the Mixin defines it and the class defines it and so on? So just so you know, here's the rule. When you are looking for a method M for some object obj, so that you can call the method, you look in obj's class. Then you look at and in mixins that it includes. Then you look in the super class, then any Mixins, then that super class includes. Then the super super class and so on. So, you check the class definition, then the Mixins and turns out you check the Mixins in order or a later include will shadow any earlier includes. I will not test you on that. I just wanted you to know that as part of a language definition you have to resolve these issues and so, Ruby did. As for instance variables, Mixin methods can get or set instance variables. If they do, those instance variables are part of the regular class. So, if methods from two different mixins both try to use the same instance variable, they could mess each other up. So, many people consider it poor style for a mixin method to access instance variables in any way. On the other hand, in other situations it is what you need to do or want to do. So, I will not resolve that style issue. I will just tell you that in terms of semantics, Mixin methods can access instance variables of the object they are a part of. So now that we've seen what Mixins are, let me show you what everyone really loves about them in Ruby. Turns out there's two Mixins that are just widely used and they make you smile, because they really make it easier to program. The first one is a Mixin called comparable and here's what it does. It defines methods less than, greater than, equals, not equals, greater than or equal to, or less than or equal to. And it assumes that any class that includes it defines just one thing, which is this three-way comparison operator. This is sometimes called the spaceship operator and what you're supposed to do with the spaceship operator is have it take two arguments. And return a negative number if the one on the left is less. Zero if they're both equal and a positive number if the one on the right is less, so let me just show that to you. I can show that to you just with numbers. The spaceship operator is defined. The number is three, spaceship four is -1, 3 spaceship 3 is 0 and 3 spaceship 2 is 1. So it turns out that on numbers, when you say is three less than two, and you get false. That is actually implemented by the comparable mix-in defining less than, to call the spaceship operator. All it's doing is it's finding less than to call the spaceship operator and then, see if the result is less than one. And if it is, then you return true. Otherwise, you return false. Let's do that for our own class. I have an example here. I have a little class name. All right, so name has three kind of fields, instance variables, first, middle and last. Here is an initializer where you pass in first, last, and middle name. And then, I define the spaceship operator. I define the spaceship operator. Take one other argument, the thing I'm comparing against and there's a bunch of logic here. I compare the last name if the last names are equal. I compare the first names. If the first names are equal, I compare the middle name, and I do all that using this spaceship operator on strings. Which is defined, which is what all these are doing, okay? And so, this is defined, so in fact, I already have over here, I already defined two names. N1 is Daniel Joseph Grossman, although I got it first, last, middle, that's not actually my name. And I made the same mistake here on n2 for Barack Obama Hussein, instead of Barack Hussein Obama but that doesn't matter. I have these two names and the spaceship operator is defined on them. So if I ask n1 spaceship n2 I get one, and if ask n2 spaceship n1 I get minus 1. If I ask n1 spaceship n1 I get 0, that's all fine, its a proper comparison but I can ask all other operators too. I can ask n1==n2, I can ask n1 not equal n2. The whole reason I can do that is just one line where in name I said include comparable, which defines all those other operators by having them call the space ship operator. That's what Mixins are all about, so let me show you the other main one that I think is even cooler. Now this one's called enumerable, so enumerable defines a lots of iterators. Lots of those high order methods that take blocks in terms of each. All you have to do as the class implementor who's including enumerable is, define each. And then, you get all the other ones for free, so I have an example of that as well. I've defined my own little range class. Of course, you wouldn't do this, because ranges are built into Ruby just fine, but this range class defines each. so the initialize methods sets a low and a high instance variable. And then, what each does is, four low up to high actually using a wire loop. It yields, so it calls the block with i then sets i = i + 1 and goes around the loop again. So, I've already created a couple of ranges over here. r1 is the range from 3 to 7and r2 is the range from 5 to 12. And of course, since I defined each, I can take R1 and I could say put S. I could pass it a block that for each thing in the range. Print it out and sure enough, I get three, four, five, six, seven and if I did that with R2. I would get five up through 12 But I also have all the other iterators too. Comparable defines them all in terms of each. So for example, count is defined in the comparable Mixin and how about I count how many of the numbers are odd. And I would get four, five, seven, nine, and 11. If I ask it on r1, I think I'll only get three, three, five, and seven. You have R1.map. You have R1.any and so on. They're all defined. They were all included by comparable and they're all defined in terms of each. The Mixin has no idea how to iterate through the elements of MyRange. Except, that it knows to each, so just call each with the block and then do the right thing with the result. So, that is what everyone loves about Ruby mixins. They are nice. I think this is a wonderful thing. You don't need the full power of multiple inheritance. Ruby style mixins are enough, but they're not a full replacement for multiple inheritance. So let me just wrap up by saying, they would work fine for our kind of 3D ColorPoints. What I have over here in the code down at the bottom is, suppose I defined a mixin color. Now, this is controversial because it's using an instance variable @color. But it defines a getter and a setter and a method darken. Then what I could do is, my 3D points could subclass point, all right. My color points could subclass point and include color. And my 3D color points could subclass point 3D and include color. And this will all workout and my 3D color points will have exactly the methods and the behavior I want. Because I only get one super class, but I can include any number of Mixins. It does not work as well for artist cowboys. So, if I want an artist cowboy, I want everything that an artist has. Everything that a cowboy has, but it doesn't really make sense to me for either artist or a cowboy to be a Mixin. A color Mixin is arguably okay, but artist and cowboy should really both be classes and if they're both classes. You cannot inherit from both of them. So that is why while Mixins are great, I think they're a really neat thing in Ruby. I would never suggest that they are full replacement for multiple inheritance.
