1 00:00:03,620 --> 00:00:07,604 In the last several videos, we have discussed code generation for a various 2 00:00:07,604 --> 00:00:11,749 simple programming language. In this video, we are going to take a look at code 3 00:00:11,749 --> 00:00:17,333 generation for more advanced feature objects. Fortunately, this dated code 4 00:00:17,333 --> 00:00:21,765 generation strategy for objects is really just an extension of what we've already 5 00:00:21,765 --> 00:00:25,765 learned. So, everything that you learn before we're going to be using and then 6 00:00:25,765 --> 00:00:30,252 there's going to be some additional things that we do specifically for objects And, 7 00:00:30,252 --> 00:00:34,710 the important thing to know about objects is slogan that you hear. When people 8 00:00:34,710 --> 00:00:40,648 talked about object oriented programming is this one. So if b is a subclass of a 9 00:00:40,648 --> 00:00:46,587 then an object of class b can be used wherever an object of class a as expected. 10 00:00:46,587 --> 00:00:52,673 So there's a substitutability property. If I have a piece of code that can work on 11 00:00:52,673 --> 00:00:58,966 a's then it could also work on b's and any other subclass of a. What this means for 12 00:00:58,966 --> 00:01:04,799 the, for the case of code generation is that the code that we generate for class 13 00:01:04,799 --> 00:01:10,141 a. So, the code that we produced for method in class a, has to work unmodified 14 00:01:10,141 --> 00:01:16,115 for an object to class b And to see this, keep in mind that when we compile a, when 15 00:01:16,115 --> 00:01:21,386 we compile class a, I, we may not even know all the subclasses of a. So, those 16 00:01:21,386 --> 00:01:26,798 maybe not even have been defined yet. So, in the future some programs may come 17 00:01:26,798 --> 00:01:34,869 along. To find a subclass of a then our compiled version of a will have to work 18 00:01:34,869 --> 00:01:42,068 with that new subclass. So, there really only two questions that we have to answer 19 00:01:42,068 --> 00:01:47,032 to give a complete description of how to generate code for objects. The first one 20 00:01:47,210 --> 00:01:51,584 is how our object represented in memory. So, we need to decide a layout and 21 00:01:51,584 --> 00:01:56,607 representation for objects And the second one is how is dynamic dispatch implemented 22 00:01:56,607 --> 00:02:01,395 so that's the characteristic feature of using objects just so we can dispatch in 23 00:02:01,395 --> 00:02:07,531 the method of an object and we need an implementation of that. So, to be 24 00:02:07,531 --> 00:02:14,197 concrete, we're going to use this little example throughout this video and I'll 25 00:02:14,197 --> 00:02:20,457 just take a moment here to, to point out some features of it. So, we have three 26 00:02:20,457 --> 00:02:27,286 classes, classes am b, and c And notice that a, is a base class and b and c both 27 00:02:27,286 --> 00:02:34,196 inherit from a, And all three classes define some attributes, some fields and 28 00:02:34,196 --> 00:02:39,800 also some methods. Now, a couple of important features here is that notice 29 00:02:39,800 --> 00:02:45,445 that because b inherits from a, and c inherits from a, they all, they both 30 00:02:45,445 --> 00:02:51,693 inherit, both of those classes inherit the attributes a, and d from class a. So these 31 00:02:51,693 --> 00:02:58,166 two attributes that are defined in class a are available in class b and in class c So 32 00:02:58,166 --> 00:03:04,492 even though there's no mention Of a, and d in the definition say of class b. The 33 00:03:04,492 --> 00:03:10,813 methods in class b can still refer to those attributes. They are part of the 34 00:03:10,813 --> 00:03:17,028 attributes of class b. They are just copied over or inherited from a. Another 35 00:03:17,028 --> 00:03:22,753 feature of this example that I like to point out is that all of the methods refer 36 00:03:22,753 --> 00:03:28,268 to the attribute a so actually referred into this method and this one referred 37 00:03:28,268 --> 00:03:34,056 twice in this method and also in this method. And the significance of this is 38 00:03:34,056 --> 00:03:40,591 just what we discussed a couple of slides ago. For all of these methods to work 39 00:03:40,591 --> 00:03:46,877 attribute a, is going to have to live in some place and some place where all of 40 00:03:46,877 --> 00:03:53,907 them can find it they generate a code run. Some particular less considered the method 41 00:03:53,907 --> 00:03:59,877 f. So the method f exists in all three classes. All three classes when it runs, 42 00:03:59,877 --> 00:04:05,603 it will refer to attribute a, and even though the objects would be different. In 43 00:04:05,603 --> 00:04:11,256 one case it might be running on an object and in another case on a c object. It 44 00:04:11,256 --> 00:04:16,113 would need to be able to find the attribute a, and so therefore the 45 00:04:16,113 --> 00:04:22,309 attribute a, has to be in the same place in each object And so, how do we 46 00:04:22,309 --> 00:04:27,116 accomplish that? Well, the first principle is the objects are laid out to in 47 00:04:27,116 --> 00:04:32,837 contiguous memory. So, an object is just a block of memory. Okay with no gaps and all 48 00:04:32,837 --> 00:04:39,118 the data for the object is stored in the words of that lock of memory. And each 49 00:04:39,118 --> 00:04:45,558 attribute is stored at a fixed off set in the objects. So for example, there may be 50 00:04:45,559 --> 00:04:51,800 a place in this object for attribute a On this case it's at in the middle of the 51 00:04:51,800 --> 00:04:57,383 object is in the, in the fourth position And, no matter what kind of object it is, 52 00:04:57,383 --> 00:05:03,508 whether it's an a. B or c objects and are example as with a we always live with that 53 00:05:03,508 --> 00:05:09,484 position so that any piece of code that refers to a, any method that refers a can 54 00:05:09,484 --> 00:05:15,901 find can find the a attribute. Now the other thing that's important to understand 55 00:05:15,901 --> 00:05:21,801 and this is you know slight digression from what we're talking about but it's a 56 00:05:21,801 --> 00:05:27,553 key aspect of code generation for object is that when a method is invoked, the 57 00:05:27,553 --> 00:05:33,601 object itself is the self parameter. So the self parameter is the entire object so 58 00:05:33,601 --> 00:05:39,146 self. When a function is involved, it will refer to the entire object so you think 59 00:05:39,146 --> 00:05:44,595 itself is going to be appointed to the entire object. Remember that self is like 60 00:05:44,595 --> 00:05:50,205 that this variable or this name in Java. And then the fields we refer to particular 61 00:05:50,205 --> 00:05:55,538 or the attributes of the object will refer to particular position within the objects. 62 00:05:55,538 --> 00:06:01,125 So, for example, the attributes, we decided to leave it there. So here is the 63 00:06:01,125 --> 00:06:06,596 particular object layout used in Kuhl. So the first three words of a Kuhl object 64 00:06:06,596 --> 00:06:12,545 contain header information and every Kuhl object always has these three entries. The 65 00:06:12,545 --> 00:06:18,153 first position is a class tag and also at zero then the next word it also four is 66 00:06:18,153 --> 00:06:23,829 the size of the object and then something called the dispatch pointer and then all 67 00:06:23,829 --> 00:06:31,901 of the attributes. Now the class tag is an integer which just identifies the class of 68 00:06:31,901 --> 00:06:36,784 the object. So the compiler will number all of the classes. So in our example we 69 00:06:36,784 --> 00:06:41,728 have three classes a, b, and c and the compiler for example might assign them the 70 00:06:41,728 --> 00:06:46,532 numbers one, two, and three. It doesn't matter what these numbers are As long as 71 00:06:46,532 --> 00:06:51,467 they are different from each other. So, it doesn't have these numbers consecutively 72 00:06:51,467 --> 00:06:56,584 or anything like that The important thing is of the class tag is a unique identifier 73 00:06:56,584 --> 00:07:01,520 for a class, each class has its own unique bit pattern that tells you what kind of 74 00:07:01,520 --> 00:07:06,756 class the object is And the other fields here the object size is also an integer 75 00:07:06,756 --> 00:07:11,213 which is just a size of the object in words and the dispatch pointer. Is a 76 00:07:11,213 --> 00:07:16,068 pointer to a table of methods so the methods are stored off to the side and the 77 00:07:16,068 --> 00:07:20,984 dispatch pointer is a pointer to that table and we'll talk about this more later 78 00:07:20,984 --> 00:07:25,900 and then all the attributes are laid out in the sub-sequence slots in some order 79 00:07:25,900 --> 00:07:30,330 that [inaudible] the compiler so the compiler will fix and order for the 80 00:07:30,330 --> 00:07:35,003 attributes in the class and then all the objects of that class will have the 81 00:07:35,003 --> 00:07:39,676 attributes of that class in the same order. And again all of this is laid out 82 00:07:39,676 --> 00:07:47,358 in the continuous chunk of memory. Now, I'm ready to talk about how inheritance 83 00:07:47,358 --> 00:07:53,067 works. So, the basic ideas like given a layout for class a, a layout for a 84 00:07:53,067 --> 00:07:59,807 subclass b, so this is a subclass of a can be defined by extending the layout of a. 85 00:07:59,807 --> 00:08:05,754 So, we don't need to move any of the attribute of a, we can just add more 86 00:08:05,754 --> 00:08:11,311 fields onto the end of a's layout. And so, that's going to leave the layout of a 87 00:08:11,311 --> 00:08:16,271 unchanged which is a great property because this is how the position of an 88 00:08:16,271 --> 00:08:21,104 attribute in the a object will always be the same for all the subclasses. So 89 00:08:21,104 --> 00:08:26,382 essentially, we will never, once we decide where an attribute lives in a class it 90 00:08:26,382 --> 00:08:31,151 will never change for any of the subclasses of that object. So b is just 91 00:08:31,151 --> 00:08:37,080 going to be an extension of the layout of a. So, let's take a look at our example 92 00:08:37,080 --> 00:08:43,179 here and see how that, that works. Let me just write down here a little bit about 93 00:08:43,179 --> 00:08:47,753 these classes because we don't have the example on the screen. So we have a class 94 00:08:47,753 --> 00:08:52,445 a, and class a, had two attributes, a, and d, okay? And it doesn't matter what their 95 00:08:52,445 --> 00:08:57,316 types are or what the methods were here. We're just looking at the class names and 96 00:08:57,316 --> 00:09:01,890 the names of the attributes that are defined in the class. And then we have b. 97 00:09:01,890 --> 00:09:10,280 Which inherits from a and b added a attribute b and then we had c which also 98 00:09:10,280 --> 00:09:20,340 inherits from a but has no relationship to b. And class c define an attribute little 99 00:09:20,340 --> 00:09:28,519 c. Alright. So, that's the structure of our example is relevant to the layout of 100 00:09:28,519 --> 00:09:33,696 the objects. Okay. So Let's talk about the layout of class a. So, in position zero at 101 00:09:33,696 --> 00:09:38,744 all sub zero, there'll be a tag for a that will be some small integer at the compiler 102 00:09:38,744 --> 00:09:43,970 picks. There'll be a size of a, we'll come back to that in just a se cond. There will 103 00:09:43,970 --> 00:09:48,543 be a dispatch pointer again, which we're going to talk about later. And then come 104 00:09:48,543 --> 00:09:53,412 the attributes of a, and it just laid out the compiler, the way it's done in the, 105 00:09:53,412 --> 00:09:58,163 the Kuhl c implementations is that they are laid out in the order in which they 106 00:09:58,163 --> 00:10:03,361 appear textually in the class. So, in this case, first the attribute a, And then the 107 00:10:03,361 --> 00:10:09,530 attribute d all sets twelve and sixteen And now since the object, there are two 108 00:10:09,530 --> 00:10:16,153 attributes and three header words that means the size of the object is five words 109 00:10:16,153 --> 00:10:22,446 and so it's a five that goes in the size field for a objects. Now, let's take a 110 00:10:22,446 --> 00:10:27,228 look at b. Okay? So b is going to have a different tag, b objects will have a 111 00:10:27,228 --> 00:10:32,491 different tag so they to distinguish them from a objects. There's going to be extra 112 00:10:32,491 --> 00:10:37,571 fields so the size will be one bigger But now the layout preserves the layout of a. 113 00:10:37,571 --> 00:10:42,835 So the attributes of a appears in the same position. So you can think of there being 114 00:10:42,835 --> 00:10:48,895 an a object Actually embedded inside of the b object. If I were to strip off the 115 00:10:48,895 --> 00:10:55,552 end here that were just you know cover up this last bit here b I would say that this 116 00:10:55,552 --> 00:11:02,209 object here has the same size and the same attributes as an a object so any piece of 117 00:11:02,209 --> 00:11:08,710 code that could work on an a object will also make sense running on a b object. Now 118 00:11:08,710 --> 00:11:13,351 Of course, the tag is different because it actually is a subclass and you know, and 119 00:11:13,351 --> 00:11:17,823 there is an extra field so the, the size is different but the point is that any 120 00:11:17,823 --> 00:11:22,748 code that it refer is just to the fields here will still work just fine. So any a 121 00:11:22,748 --> 00:11:27,559 method that was compiled that refer to the methods of an a object will still find 122 00:11:27,559 --> 00:11:32,314 those attributes in the same place at the b object and afterwards, there is also one 123 00:11:32,314 --> 00:11:36,624 more field here. Which is the new attribute b It just gets laid out after 124 00:11:36,624 --> 00:11:41,164 all of a's fields. So after all of a's fields come all of b's fields in the same 125 00:11:41,164 --> 00:11:45,477 order which they appear textually in the class because there's just only one, 126 00:11:45,477 --> 00:11:50,202 there's just one new field there. And now looking with class c or the story with 127 00:11:50,202 --> 00:11:54,875 class c is very similar so c has its own distinct tag and also has one more 128 00:11:54,875 --> 00:12:00,238 attribute than a so it has size six. And now again the a attributes were on the 129 00:12:00,238 --> 00:12:06,319 same position and now the c attribute just comes after the a attribute. And so notice 130 00:12:06,319 --> 00:12:11,985 here that a methods again will work just fine on c objects because the attributes 131 00:12:11,985 --> 00:12:18,066 are on the same places and so the methods will find the attributes where they expect 132 00:12:18,066 --> 00:12:23,498 to. You cannot however call a method of class b on an object to class c. Okay 133 00:12:23,498 --> 00:12:28,842 because they have different attributes in the third position. We may have completely 134 00:12:28,842 --> 00:12:34,059 different types. It may not make sense to invoke a b method on c object but that's 135 00:12:34,059 --> 00:12:39,085 just fine because if we look in our [inaudible] over here we'll see that b and 136 00:12:39,085 --> 00:12:43,666 c are actually unrelated. They are both subclasses of a but they have no 137 00:12:43,666 --> 00:12:48,819 relationship to each other. B is not a subclass of c and c is not a subclass of b 138 00:12:48,819 --> 00:12:53,273 and so anything beyond their shared ancestry with a can be completely 139 00:12:53,273 --> 00:12:58,860 different in the layout. So, more generally, if we have a chain of 140 00:12:58,860 --> 00:13:04,754 inheritance relationship, so let's say, we have a base class a1 and a1 inherits some 141 00:13:04,754 --> 00:13:11,358 a1 and a3 inherits some a2 and so on with some class a and inheriting at the bottom 142 00:13:11,358 --> 00:13:17,251 of this of this chain after some long sequence of, of other intermediate. Some 143 00:13:17,251 --> 00:13:22,648 classes, you know, what is the layout of all these classes going to look like. 144 00:13:22,648 --> 00:13:28,039 Well, there's going to be a header. Okay, the three word header and that will be 145 00:13:28,039 --> 00:13:33,620 followed by a1's attributes. And then followed by a2's attributes followed by 146 00:13:33,620 --> 00:13:40,157 a3's attributes and so on all the way down to an's attributes down here. Okay. And if 147 00:13:40,157 --> 00:13:46,166 you look again so what we talked about before each prefix. Of this header is 148 00:13:46,166 --> 00:13:51,837 essentially a valid object a valid one of these objects. If I look at the first set 149 00:13:51,837 --> 00:13:57,046 of attributes, everything up to the end of a1 and attributes, that forms a valid 150 00:13:57,046 --> 00:14:02,321 layout for one object is I stop with the a2 attributes. I have a, I have a, I have 151 00:14:02,321 --> 00:14:07,793 a valid layout for a2 object going all the way from the header down to you know, 152 00:14:07,793 --> 00:14:13,464 including the a1 and a2 objects. And then a3 includes all a1, a2 and a3's attributes 153 00:14:13,464 --> 00:14:20,268 and so on. Okay? So, each prefix Of, of this object, Of this a and object has a 154 00:14:20,268 --> 00:14:28,948 correct layout for some for some super class of a. Not that we dealt with the 155 00:14:28,948 --> 00:14:35,168 layout of an object's attributes, we can switch gears and talk about how we layout 156 00:14:35,168 --> 00:14:41,389 its methods and how we implement dynamic dispatch. So, let's consider a dispatch 157 00:14:41,389 --> 00:14:47,356 called e.g where e here, let's say, is a class b. Okay? So what do we wanted to 158 00:14:47,356 --> 00:14:52,725 have happen? Well, we want to invoke the g method here in class b, okay? So that 159 00:14:52,725 --> 00:14:58,095 seems pretty straight forward. So now let's consider a slightly more complicated 160 00:14:58,095 --> 00:15:03,666 example. What if we are invoking e.f of if we're calling the f method? Well, if we 161 00:15:03,666 --> 00:15:10,734 have a b object. Then we are going to want to evoke this method, this f method, okay, 162 00:15:10,734 --> 00:15:17,448 which is the f method to find in b. But if we have an a object, we want to be sure 163 00:15:17,448 --> 00:15:23,602 that we invoke this method, okay, this version of f. Alright, and so, this f down 164 00:15:23,602 --> 00:15:32,914 here is said to be overridden. Okay. So, we have redefined. Method f in class b and 165 00:15:32,914 --> 00:15:38,209 this definition replaces the method definition that b would otherwise have 166 00:15:38,209 --> 00:15:44,140 inherited from a so in particular in class c, class c also have an f method okay and 167 00:15:44,140 --> 00:15:50,071 if we invoke the f method, if it turns out that e here is a type c then which method 168 00:15:50,071 --> 00:15:55,931 should get involved? Well it would be this one. It would be the one defining class a 169 00:15:55,931 --> 00:16:01,653 so all three of these classes has an f method. If the, if we do a dynamic 170 00:16:01,653 --> 00:16:09,047 dispatch on either a c or a object or execute the one defining class a. If we do 171 00:16:09,047 --> 00:16:16,837 the dispatch on the b object, we will execute the method defined in class b. Now 172 00:16:16,837 --> 00:16:22,954 every class has a fixed set of methods including the inherited methods. So if 173 00:16:22,954 --> 00:16:29,151 you, if you look, if I tell you the name of a class, then you know exactly which 174 00:16:29,151 --> 00:16:35,310 methods it has. Those methods never change at runtime. Okay? So don't be confused 175 00:16:35,310 --> 00:16:40,028 here because overriding is something that's done at compile time is basically a 176 00:16:40,028 --> 00:16:44,923 static property. South compiler can figure out even though you can redefine methods 177 00:16:44,923 --> 00:16:49,700 in subclasses the compiler can figure out a compile time all the methods of a 178 00:16:49,700 --> 00:16:54,267 particular class. Methods never change while the prog ram is executing. Alright 179 00:16:54,267 --> 00:16:59,363 So, a dispatch tape of there's a table of some sort is used to index these methods 180 00:16:59,363 --> 00:17:04,024 and this is just in the ray of method entry point. So, essentially for every 181 00:17:04,024 --> 00:17:09,058 method of the class there's an entry in the ray for that method. And just like 182 00:17:09,058 --> 00:17:14,432 with attributes, the method f is going to live at the fixed offset. In the dispatch 183 00:17:14,432 --> 00:17:19,997 table for a class and all of its subclasses so once we determine the 184 00:17:19,997 --> 00:17:26,516 position that a method lives in. It lives in the dispatch table; it will stay there 185 00:17:26,516 --> 00:17:33,506 for any subclasses of that class. So let's take a look at our example again and just 186 00:17:33,506 --> 00:17:40,138 a reminder the structure of the example we have class a and now we only really care 187 00:17:40,138 --> 00:17:46,296 about the method so class a define an f method and then we have class b which 188 00:17:46,296 --> 00:17:55,345 inherits from a. And that define the g method. And then there was the class which 189 00:17:55,345 --> 00:18:04,882 also inherits from a which defines an h method. Alright so those three classes and 190 00:18:04,882 --> 00:18:12,247 these methods, Okay? And so the dispatch table for class a only has one method in 191 00:18:12,247 --> 00:18:18,234 it so it's also at zero. We store a pointer to the code for the f method 192 00:18:18,234 --> 00:18:24,222 define an a, okay? So this is actually literally just a pointer to the first 193 00:18:24,222 --> 00:18:30,209 instruction of the code that will run method a. So this is a pointer to the 194 00:18:30,448 --> 00:18:37,234 caller side or the calling sequence or the label labeled instruction as the entry 195 00:18:37,234 --> 00:18:44,247 point for the method. Now, what about let's take a look next actually at class 196 00:18:44,247 --> 00:18:49,033 c. Okay? So class inherits from a. So what's going to happen with all the 197 00:18:49,033 --> 00:18:54,448 methods of a and they're going to be at the same off sets. So in particular, the f 198 00:18:54,448 --> 00:19:00,198 method will appear at offset zero in class and this points to the same method as the 199 00:19:00,198 --> 00:19:06,706 one in a And so this inherits that method from a and then class c defines its own 200 00:19:06,706 --> 00:19:13,330 method h and so in the next position of the table goes the pointer to the code for 201 00:19:13,330 --> 00:19:18,415 h. And, you know, there have been more methods defined in this classes than they 202 00:19:18,415 --> 00:19:23,153 would have appeared you know, laid out in textual order just like for the 203 00:19:23,153 --> 00:19:28,016 attributes. So, if there have been, say, two methods defined in a, then there will 204 00:19:28,016 --> 00:19:33,440 be two entries here fo r the first method and the second method define an a and then 205 00:19:33,440 --> 00:19:38,740 c define a three method then there will be three more entries in the table and so on. 206 00:19:38,740 --> 00:19:45,563 Okay. Now the interesting case is what happens in class b. So in class b the f 207 00:19:45,563 --> 00:19:52,162 method is redefined and I forgot to indicate that so let me just indicate that 208 00:19:52,162 --> 00:19:58,510 up here so the f method, we have a new definition of the f method in class b. 209 00:19:58,510 --> 00:20:03,717 Okay so the important thing to see here is that the pointer to the code for the f 210 00:20:03,717 --> 00:20:08,735 method lives in the same position. It's still the first entry in the table, okay 211 00:20:08,735 --> 00:20:13,879 so the position of the f method in the dispatch table for class b is exactly the 212 00:20:13,879 --> 00:20:19,428 same that never changes. What's difference is just the contents of that location. The 213 00:20:19,428 --> 00:20:24,652 first entry in the table here points to a different function. It points to the 214 00:20:24,652 --> 00:20:30,143 method that was defined in b instead of the one that was defined in a. And then 215 00:20:30,143 --> 00:20:36,371 since b defines some additional methods or one additional method that gets laid out 216 00:20:36,371 --> 00:20:43,290 after the methods for a. You may recall a while ago that we talked about the object 217 00:20:43,290 --> 00:20:48,630 header and we mentioned this thing called the dispatch pointer so this would remind 218 00:20:48,630 --> 00:20:53,715 ourselves what goes in the object header. There is the tag and then there is the 219 00:20:53,715 --> 00:21:00,293 size and then there was a dispatch pointer so And then following dispatch pointer 220 00:21:00,293 --> 00:21:06,993 where all the, all the attributes of the class And now this dispatch pointer is 221 00:21:06,993 --> 00:21:13,608 just a pointer to the table of methods for that class, okay? So this would be a 222 00:21:13,608 --> 00:21:19,470 pointer to the table. That contains all the entries for the methods, all the entry 223 00:21:19,470 --> 00:21:24,724 points of the methods for that class. And the reason for using this level of in 224 00:21:24,724 --> 00:21:29,422 direction and so, why do we have this pointer to a separate table and so, why 225 00:21:29,422 --> 00:21:34,182 are the methods laid out like that when all the attributes are just embedded 226 00:21:34,182 --> 00:21:39,128 directly in the class And we could, if we wanted to just embed all the functions 227 00:21:39,128 --> 00:21:44,073 directly inside the object and, ad, you know, out this whole table inside t object 228 00:21:44,073 --> 00:21:49,390 and, and not have this extra pointer that we have to, we have to maintain and follow 229 00:21:49,390 --> 00:21:54,543 And in the reason for this is th at the attributes are, can be updated. Okay, So, 230 00:21:54,543 --> 00:22:00,098 the attributes for a and object can be unique object. Every object and have its 231 00:22:00,098 --> 00:22:05,653 own set of attributes so alright But the functions, the methods for an object never 232 00:22:05,653 --> 00:22:10,826 change. And so the same object table can be shared Between all the objects of a 233 00:22:10,826 --> 00:22:15,801 given class. So if I have 100 a objects well then I might have 100 different 234 00:22:15,801 --> 00:22:20,524 version of the attributes and so each a objects has its own copy of the 235 00:22:20,524 --> 00:22:25,624 attributes. But all those 100 a objects will have the same methods and I can save 236 00:22:25,624 --> 00:22:30,676 a lot of space by having them share a common table of the methods And again 237 00:22:30,676 --> 00:22:36,468 every method of the class or every class is a sign and offset and we'll call that 238 00:22:36,468 --> 00:22:41,765 Os of f. In the dispatch table compiled times. So the job of the compiler to 239 00:22:41,765 --> 00:22:47,416 figure out all the methods of the class and then assign each of those methods, a 240 00:22:47,416 --> 00:22:55,021 fixed position, a fixed offset in that dispatch table, So to wrap up, how do we 241 00:22:55,021 --> 00:23:00,594 implement dynamic dispatch? So let's say we have a dispatch to an expression e and 242 00:23:00,594 --> 00:23:06,099 we're calling the f method. So, here's the, a slightly simplified version of the 243 00:23:06,099 --> 00:23:11,400 sequence of steps. So first, we evaluate the expression e and that's going to give 244 00:23:11,400 --> 00:23:16,587 us back an object x. Okay, and then we are going to get the dispatch table for x, 245 00:23:16,587 --> 00:23:21,713 where that does come from. Well, it's in the header of x so we can just take the 246 00:23:21,713 --> 00:23:27,292 object x itself and we know that in every object at the, in the third word there is 247 00:23:27,292 --> 00:23:32,548 a dispatch pointer for the, that's appropriate to the class of x. So, we take 248 00:23:32,548 --> 00:23:38,063 that table and then we look up the entry point of f at the offset For f in that 249 00:23:38,063 --> 00:23:44,156 dispatch table And then we'll jump to that to that address, okay? That's the entry 250 00:23:44,156 --> 00:23:49,960 point of the function and, and when we do that, we're buying self to x. So the, the 251 00:23:49,960 --> 00:23:54,240 self parameter inside of the f method will be the x object.