>> [music]. In this segment I want to show you how Ruby is a very dynamic language. Just about anything can change while the program is running. We've already seen that with instance variables. That we can take any object, and add any instance variable to it just by assigning to it in some method of the class. Now I want to show you that classes themselves can have their definitions changed while the program is running. So the idea is that any code running in your Ruby program or anything you type at the rebel, can add, change replace methods. At any time during program execution. Now I don't particularly love this feature, because it makes programs pretty much impossible to analyze. It lets any code break any abstraction just by changing the definitions of methods, but it does have some[LAUGH] interesting even convenient uses. For example, if you really wish that some common class like String or Ray or Number had some super useful helper function, you could just add it. And then it's like it was in that class definition all along. >> I'm not saying this is a great idea for large programs, but it's an interesting feature for scripting languages, and it's certainly something that people enjoy using. For our purposes here, it really just helps me emphasize the idea of object oreinted programming. That every object has a class. And a class determines its instances' behavior. And since classes themselves are just objects we can modify those objects by adding or removing methods. So let me show you the idea just over here in the REPL with some examples. I have all this in a File as well. Everything would work in a file. I will post that file with the lecture materials. But suppose that I start by loading the larger example I had from a couple segments ago with my rational numbers. So I can have, make my rational for sort of nine comma six. And that is the fraction three slash two. The repple is calling the 2s method for me, that's why you see 3 2 over 2 being printed. If I explicitly convert it to a string, you see it that way. But my purpose here is to emphasize that while I have an add method, you know, I can say x plus x and get 3, boy that's super inconvenient. I really wish that instances of my rational had a double mtehod for doubling themselves. And it's simply not defined. If you go back and look at the code I wrote in that class it's not there. Well, let's just change it. They way you change a class definition in Ruby is you just make class definitio with the same name and you add more stuff to it. So here class my rational Well, let's make a method double. What I could just do is take the object itself, so this is going to be part of an instance of my rationals, so self will be some fraction, and call the plus method on it with itself again. Close the method, close the class and now if I made a myrational dot new, maybe 3,4 That's fine. I could still convert it to a string. I could still call plus with it. But I can also now, say double. So 3 4ths doubled to 3 halfs. If I said y dot double dot double, I get three. Because self plus self ended up returning the object itself. That's how our addition worked. And so on. If I did it one more time I think I would get six. Alright. Now, here's the cool part. [inaudible] x, which I defined way up here before class MyRational even had this method, can double itself to and that's because every object has a class. Once the class changes, objects of that class See the reflective changes. That's an interesting semantics, it's fairly natural and it lets you change the behavior of objects that even already exist. In fact let me show you something else, if we like this doubling so much, how 'bout we add it to numbers too. So you know, things like three have class fixnum. Oh, I have we'll just try that again. I think I forgot punctuation somewhere. There we go. That time it took. Remember, three.class is a fixnum. So now three knows how to double itself. In fact, so does 42, and so on. So people that's neat. I'm just using it to teach object oriented programming. Let me show you one other thing we know we can define methods at top levels. So what I just define a little method here that always returns 42? So it turns out that this just added a method to the object class because that's where top level methods go. It turns out that here in the repl, I really am part of the object class. And so now all objects have this m method. So if I say x dot m, I get 42. If I say 56.m, I get 42. [inaudible]. In fact I really did just add it to the object class. Because if I say 56 dot methods. You will see in this list somewhere, M. And if I said nil dot methods you should also see in here somewhere M. I won't try to find it right now. And in fact, if I did it the more explicit way and said 43 instead. Now I've replace the old M method from a minute ago with this new one. And now I get 43, no matter how I call that method. Even at op level I get 43 because I just replaced a method that was already there. Now replacing methods to behave differently is obviiously rather suspect. And what I thought I would do to finish up my irb, I purposely saved this to last, for reasons you'll see in just a second, suppose I took the built in Fixnum class, and changed its addition operator so that it still takes one argument, x. But it, when you call it, it just returns 13. And what apparently just happened is I just crashed and you're seeing all sorts of weird stuff on my screen, because when you change A definition like plus,[UNKNOWN] IRB, which is it self written in Ruby and calls all sorts of Ruby code. So it's doing all sorts of strange things. So that's why I saved that to last. Ok. So, the moral of this story here, so when you have a very dynamic language some interesting semantic questions came up. One of the things I've showed you here was what happens if you create an instance of some class Replaces method M, and then called the method. Do you get the old method since the object is created before the class change, or do you get the new method because you look up in the class, as it's currently defined? It turns out in Ruby you get the new method. That's considered the more useful semantics. But my real point is in languages that are less dynamic, that don't have this sort of ability to change classes at run time. This question never comes up. So, more dynamic lanauges tend to introduce more questions of semantics that a language definer, someone designing the language, has to answer. Because this is a semantic question that you have to answer in your language. But if your language doesn't have such a feature Then it's an irrelevant question and your language implementation might be easier or even faster, higher performance because it doesn't have to deal with such situations. And that's an interesting thing in Ruby, dynamic class definitions that's unlike many of the object oriented programming languages you may have seen previously.
