What's the point of Object Orientation?
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Part Number | 76 | |
| Number of Parts | 169 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/21155 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Computer programObject-oriented programmingSound effectCausalityBitDimensional analysisEncapsulation (object-oriented programming)Arithmetic meanProcess (computing)Statement (computer science)Branch (computer science)Functional programmingComputer programmingProgramming languageGreatest elementLink (knot theory)TouchscreenInsertion lossWordSoftware frameworkEndliche ModelltheoriePhysical systemMultiplication signGoogolNatural numberProgrammer (hardware)Social classWaveProjective planeMechanism designVideo gameSelf-organizationInheritance (object-oriented programming)Goodness of fitProgrammschleifeWeb pageWeb 2.0Real numberBuildingQuicksortWeb applicationLecture/Conference
04:26
CodeLine (geometry)Data modelSet (mathematics)SubsetObject-oriented programmingFinitary relationMultiplizität <Mathematik>Positional notationOperations researchSet (mathematics)Computer programmingMathematicsMappingLevel (video gaming)Object-oriented programmingQuicksortDisk read-and-write headEndliche ModelltheorieBitArithmetic meanConnected spaceOperator (mathematics)MaizeMultiplication signInformationData structureExecution unitSubsetTheory of relativityLine (geometry)AveragePhysical systemTheoryTrailView (database)Real numberTerm (mathematics)CodeElectronic mailing listStructural loadNumberComputer filePoint (geometry)Data compressionVideo gameType theoryContext awarenessPositional notationWordVenn diagramOffice suiteCASE <Informatik>State of matterRight angleOrientation (vector space)CausalityNetwork topologyLogical constantDiagramMultiplicationSound effectVirtual machineDiagram
13:23
Operations researchOnline helpComputer programFocus (optics)Zoom lensClassical physicsType theorySocial classPermianAttribute grammarInflection pointThermische ZustandsgleichungLibrary (computing)Thomas KuhnInheritance (object-oriented programming)Radio-frequency identificationFile formatInfinityMeta elementWide area networkStatisticsUniform resource nameComputer fileBlock (periodic table)Disk read-and-write headLine (geometry)Object-oriented programmingMultilaterationTheory of relativityQuicksortType theoryPointer (computer programming)Functional (mathematics)Different (Kate Ryan album)Instance (computer science)Data structureSoftware testingParsingWritingOperator (mathematics)NumberImplementationSubsetSystem callFile formatLink (knot theory)Parameter (computer programming)Execution unitCodeAlgorithmBitSocial classMappingExpressionComplete metric spaceTheoryOnline helpClassical physicsTerm (mathematics)Limit (category theory)Real numberException handlingInsertion lossSlide ruleMoment (mathematics)Right angleInheritance (object-oriented programming)Master-GleichungNeuroinformatikProgramming languageSupersymmetryAttribute grammarMereologyHTTP cookieOrientation (vector space)Process (computing)Gene clusterWordPoint (geometry)Extreme programmingArithmetic meanLecture/Conference
22:20
Metropolitan area networkGoogolGroup actionSlide ruleCode refactoringObject-oriented programmingAmsterdam Ordnance DatumEmailGamma functionRun time (program lifecycle phase)Social classInterface (computing)ImplementationPhysical systemPresentation of a groupSubject indexingTerm (mathematics)Java appletCodeLevel (video gaming)InformationAbstractionProgramming languageProduct (business)Limit (category theory)Arithmetic meanFiber bundleFunctional (mathematics)1 (number)Traffic reportingObject-oriented programmingHypothesisReal numberFunctional programmingClient (computing)Inheritance (object-oriented programming)Table (information)Transformation (genetics)Statement (computer science)MathematicsMultiplicationProcess (computing)Filter <Stochastik>Link (knot theory)Software testingWordPlanningExecution unitRevision controlEmailVideo gameBitSorting algorithmMultilaterationMechanism designOrder (biology)Letterpress printingRow (database)Type theoryCode refactoringGoodness of fitAttribute grammarDecision theoryTracing (software)TouchscreenUniverse (mathematics)Multiplication signDisk read-and-write headDifferent (Kate Ryan album)Operator (mathematics)Student's t-testView (database)Point (geometry)Right angleElectronic mailing listComplete metric spaceLattice (order)Dynamical systemInsertion lossPower (physics)Medical imagingHecke operatorContrast (vision)Endliche ModelltheorieLogic gateState of matterBoolean algebraCASE <Informatik>Computer programmingGamma functionExterior algebraMassGoogolCausalityMixed realityParameter (computer programming)DataflowEncapsulation (object-oriented programming)Slide ruleCuboidSource codeAxiom of choiceLecture/Conference
Transcript: English(auto-generated)
00:02
Hello everyone. We are ready to talk about object orientation, and Ivan Vosloh will present us some ideas about that. Thank you.
00:24
Good morning everyone, and a big thanks to the organizers who seem to be doing really well again this year. I sort of live a double life. In the Python world I am behind a project called Real.
00:44
It's an experiment where we're trying to build a web framework where you can express your whole web application using Python only. No CSS and JavaScript and HTML and all that, but rather words like Python classes like I have there on the screen.
01:01
We can do really cool stuff already, like this complicated example is all hidden behind one class. I'm not talking about that this year, because I did last year and the link there at the bottom is to the talk of last year if you're interested. Go and check it out and help us.
01:22
So rather than sticking to the same topic, I thought I should pick something from my day job, where I've spent a lot of time in the last decade sitting with programmers who are working on big systems, systems that have grown for 10, 15 years,
01:41
and they struggle with these things. There was once a guy who struggled to add a button to a page for an entire week. So my job there is to mentor these people and help them to improve the design of these things and to test them and stuff like that. One of the things that I realized is that there are very basic things about object orientation that are used in ways they weren't intended to,
02:09
and then they tend to make things very difficult for these people. And I always wonder about this, and if you go and look on Google, the way object orientation is introduced usually is by means of things like inheritance and encapsulation,
02:25
and all kinds of stuff that really, those things are the tools, they are not the point, they are not what it's all about. So the stuff that I'm presenting today are very, very basic, but I hope you've never seen it before.
02:41
It actually comes out of books and things that were written in the 90s and before that. So first things first, object orientation really is not about object oriented programming, there is a lot more to it.
03:01
The whole idea is that you want to actually express how you understand the problem domain, and build something that we call a conceptual model, then you'll map it to a programming language, to code in some kind of programming language, which does not need to be an object oriented programming language, in fact some functional programming languages can work well too.
03:27
But if you have an object oriented programming language, then you will have some supporting mechanisms in there, as Python gives us. So I'm going to focus a little bit more on the beginning of all of this, the conceptual models.
03:45
I don't know if you know this old game, it was a very cool game, it's all about cause and effect, and I actually think that this is how a lot of people understand their programs. Something happens and then something else happens, which triggers something else to happen, etc, right?
04:05
Programs are a little bit more complicated though, because we can branch, we've got if statements, we've got loops and so on, which means that the trace that you will follow through a program could be different each time. So that's a little bit more complicated to understand, but you probably think that you do understand a program of this size.
04:27
What if it's like a hundred lines of code? Can you still understand all of that and know what any change will affect elsewhere? You probably can, maybe, maybe you're really smart, but the sort of systems on average that
04:44
I tend to work with are more like a hundred and eighty thousand lines of code. And I can't understand them. So what does it take to understand a program like that? We have this thing in our heads that has evolved over millennia, called an understanding, that helps us to basically determine what we should care about,
05:07
what represents danger, what represents opportunity, and this is sort of a built-in feature that we have. And if I say, what does it mean to understand a program, I'm really asking, can we use this machinery that we already have to better manage programs?
05:25
If you don't, then you have this maze of your code in your head, all of it, because you need to know how to navigate from one place to the other, and there's no meaning there. So let's talk about conceptual models, because understanding is all about conceptual models.
05:46
If I have to explain something to you, I'll probably explain things in terms of concepts, right? So conceptual models are really all about concepts, and concepts are actually quite cool things.
06:01
In this example here, I've got a concept chair in my head, and you can see there that it applies to two of the objects in my awareness, two chairs over there. So what I can do now is, if I know something about chairs, if I have some information about it, for example that they're useful because you can stand on them if you want to change a light bulb, right?
06:23
I can save that information only once, and I know that it applies to both of those. If I didn't have this concept, I'd have to store that information twice, so it's a compression algorithm. But the really important thing about concepts also is that we give them meaning by means of giving them a definition.
06:46
So I can define what a chair is, and that definition helps me when something new comes into my awareness that I've never ever seen before. I can use this definition to decide, oh, but does this new thing actually, does one of my concepts actually apply to this new thing?
07:05
And if it does, everything that I've learnt about chairs in my entire life all of a sudden become useful in connection with this new thing. That's really actually quite amazing. From a mathematical point of view though, we model concepts as sets.
07:24
So a chair, the concept chair, can be the set of all chairs, and so with desks as well. And this provides the foundation for everything object-oriented because everything that you know about set theory and mathematics also can help you to reason about oh-oh stuff.
07:44
One important thing, concepts in my head aren't just a list, an unstructured list of concepts. They actually have an intricate structure. One of the things that give rise to this structure is that we also have subsets here.
08:03
So an office chair in this example also confirms to the definition of chair, but maybe we can say a little bit more about office chairs. It's a bit of a more specialized kind of concept, right?
08:20
So this is the one thing that gives rise to structure. The other thing is that I can actually connect objects from one set to objects in another set. In this case, I drew some lines there to show that one chair is assigned to a particular desk and another chair is assigned to another desk.
08:42
But this sort of picture should be familiar to you as well if you think of mappings and relations and so on in mathematics. But there's another way also to look at this. If you take all of that stuff away and you just keep the connections, there are two of them. So they can be a set as well.
09:01
So this set of connections is also a concept and this relation is the concept of assignment in this particular example. Before I move on, just a quick detour. We like to specify a little bit more about relations and we call that multiplicity.
09:21
So we would like to always say, well, in this particular example, more than one chair can be assigned to the same desk but not the other way around, right? But it becomes a bit complicated to talk about these things and to denote them using Venn diagrams, right?
09:42
So in the 90s, before then, I think a lot of people came up with a lot of notations for dealing with this stuff. And finally standardized UML, which you probably know. And this exact picture that I have here is the same as you saw in the previous one.
10:03
And I guess you all must know UML but I'd like you to look at it possibly with different eyes, thinking that chair here is a set of which office chairs form a subset that I can say something more about, which is, oh, they could be assigned to desks.
10:24
But we don't actually program with chairs and cars and stuff like that, right? So it also isn't about physical objects, that's not what object orientation is about. It's about concepts and most concepts are actually intangible things because they really just exist in our heads.
10:45
This is a real world example from the investment industry. So there could be a concept called investment instrument, which is something I can buy and I hope that it will become worth more over time, right? A subset of those things are called unit trusts, they work in a particular way that are slightly different to other investment instruments, right?
11:10
And I can have something like a portfolio that's a way for me to keep track of all the things that I own. None of these things really exist in the real world, they're all intangible and
11:22
only exist in our heads and we keep inventing these things as we go on. Something you need to know though is that our heads are very flexible. For example, sets can overlap, so I can be both a person and an investor at the same time.
11:42
Actually, it gets worse because how I am classified can change over time. So I can be a person and eventually also be an employee and at some stage also become an investor and then maybe stop being an employee again. That's how we think about the world.
12:02
It's time for me to change terminology though because no one really talks about concepts, even though all of this stuff is based on concepts and the definitions that I've talked about up to now. But the word concept is merely a label that I've attached to concept so that I can talk to you and explain to you the concept of a concept.
12:26
Typically in OO, of course you can attach more than one label to a concept and in OO the label type is more commonly attached to what I've explained right now. Those of course are synonyms, so from now on I'm going to try and switch terminology but please don't forget concept.
12:47
Things get interesting only when we actually make changes to objects and that is where operations come in. An operation is also a concept. Its definition basically says what it is that you want to happen to a number of objects.
13:10
So it operates on a number of objects. In this particular example, load prices is something that can create a bunch of prices and attach them to unit trusts based on the data in a price file.
13:25
Please note that I'm not saying how you do this, there's no algorithm here or anything, this is just what it means and that's what concepts are all about. They impart meaning, right? At the end of the day though, we also need implementations for these things and this is where methods come in.
13:46
Operations are implemented by methods and an operation can be implemented by many methods because there's many different ways to do something, right? The same thing. A quick summary then, what we've covered so far.
14:02
So let's say, just for argument's sake, that we will view anything we'll call anything in the world an object. A subset of those things are called types or concepts. Types are special because they can have subtypes and they classify other objects.
14:25
A special kind of type is a relation and relations link objects together, right? And another special kind of type is an operation which operates on a bunch of objects and gets implemented by a number of different methods.
14:44
You can sit with a head full of concepts, how does that help you? Because you still have this spaghetti bowl of code lying somewhere. What's the point? How does this help us? Well what you can do is you can forcibly structure your code in a way that conforms to the structure of the concepts in your head.
15:05
In this particular example, if you take the blue block there, you can sort of block out a lot of detail and say, okay well this is a method. And it's a method that has to do with parsing CSV files, right? You can block out the red block there and say, well this is also a method, it's the method that I use to parse XML files.
15:28
You can actually put them together and block a bigger piece out of detail and just say, okay this has to do with operation. Of parsing files. And if you take this to its logical extreme, you end up in a place where you
15:44
can really just think of your code in terms of the concepts that are in your head. Which means that all of that detail that sits in that code, you can forget about it because you can just focus on what you really want to. For example, I can explain to you that a price file has a particular file format.
16:05
Tomorrow perhaps it's interesting to know that there are two kinds of file formats, the one is Excel and the other one is CSV, right? And I can know absolutely nothing or need to know absolutely nothing about Excel if I just want to look at the method for parsing CSV files.
16:28
So where does Python really come into all of this? There are basically two kinds of object-oriented languages. The one sort is prototype-based, that's what JavaScript does.
16:43
Python conforms to the classical object-oriented programming languages. So I'm going to quickly run through that just to explain how what I've talked about up to now actually maps to Python. Well, we need some way of actually saying, expressing the types in our head in Python, and this is where classes come in.
17:07
But please note that a class is a much more restrictive thing than a type, which is a more theoretical thing. Classes are like cookie-cutters, you can create instances and all those instances are
17:23
the instances that are classified by that class or that that class applies to. You can't change the class of an instance, there are a couple of restrictions like that. Just to show you, I'm not talking nonsense, there's a doc test to show that it works, right?
17:45
For relationships, we've got something equally simple. We don't have anything like a relationship that can actually attach two different things, we just have a one-way pointer. And that's an attribute, so if a portfolio has an owner attribute, it can point to another object somewhere else, right?
18:09
And that's all we have, so anything we want to do with relationships has to be built on top of this. And once again, just to show you that it actually works, right?
18:22
Methods and operations are interesting, because they're actually both present in Python, but operations aren't there explicitly. They're sort of there in ghost form, and I'll talk about that a little bit later. But you know that a method is basically just a function in Python?
18:41
Except for the one other strange restriction, and that's that the method has to belong to a class. That's also something that theory doesn't actually expect. But to make things work in the real world of computers, we have to live with this limitation.
19:04
Obviously, the other interesting thing that Python does is it allows you to... It has a little bit of a trick. If a method is a function, you could call it like I wrote there, you could call it on the actual class and pass the instance in, right?
19:20
But Python just has a little bit of syntactic sugar, which has an important role to play, so that we can call this method on the actual object, right? I'll talk about that in a moment again. Just for completeness sake, I had to put the slide in here, otherwise the other examples won't work, so we do initialise instances, right?
19:44
But more importantly, subtyping. And this is probably one of the most misused things in the world. So, to be able to express this idea of subtyping, we have inheritance.
20:01
What happens in Python, of course, when you create a class that inherits from another one, is that this class will also have the methods of its superclasses. In other words, people think that it's about reusing the code. It's actually not. It's an expression of your intent. It says, oh, but a unit trust fund actually
20:24
is a concept in my head which conforms to the definition of an investment instrument. And just, again, a doc test to show you that it works. Let's get back to operations, though.
20:43
Let's say I've got this scenario where I've got two different file formats, and I've got an operation parse. Now, remember, an operation is a concept, so it's got a definition. The definition of parse here perhaps means that a parse operates on two things, a file format and a file.
21:03
And it will return to me the data that's in that file, maybe line by line, for example. What we would do in Python is we would actually write two different methods, right? We'll have a parse method on CSV file format that has a particular implementation, and a totally different implementation on the Excel file format, right?
21:27
The way Python actually knows that these things are different implementations of the same operation is because we gave them the same name. It allows us to write code like this. Assume that a price file has a file format,
21:44
then you can say for line in price file dot format dot parse, this particular file, right? In other words, when you look at this code and when you have to understand this code, you can make use of this concept of parsing files without having to know the details of how it's going to work.
22:03
You don't even have to know that there are many file formats, you just must understand the definition of the concept parse, that's all. If we didn't have that, you're going to have to write something like this, and there are a lot of things wrong with this.
22:24
Just a few quick words on design. When you think about a conceptual model, when you discuss things and debate things with a business person, for example, you live in this world where you could come up with a model like this.
22:45
A person that can become an employee and eventually not be one anymore, etc. The problem with this is that it's not implementable. We understand it pretty well, but we can't implement it. This is what design is all about. You can, though, take that design and
23:01
come up with a different understanding that you also understand equally well, but it's implementable. In this particular case, we decided to think about it a little differently and say, well, perhaps a person can have roles, and there are two types of roles, employee and investor, and I can add roles and take roles away during the lifetime of a person.
23:23
This gets the same job done, but it's implementable. So that's what design is all about. Of course, design is a difficult thing, and I would never be able to make statements about it quickly and easily, but you do get worse design and better design.
23:44
Just to give you a feel for why this is important, I've got this picture up. This is actually a real world example from one of my clients who would like to stay anonymous. It has been reverse engineered from actual code. It's got to do with how commissions are being calculated in an insurance company.
24:10
I would never be able to explain to you how this company thinks about calculating commissions using this, because most of the things on here really don't impart any meaning to me at all.
24:26
They are merely there because someone needed something to put a method on and didn't quite know what to call it, right? I sat with this exact stuff, went through this code, I can't remember, I think it took me about two weeks, and came up with this. Can you see the contrast?
24:48
I can actually use this. I can use this to explain something to you. I can say, okay, when we do a quote, we quote for particular scenarios, and a quote scenario is composed of a bunch of benefits.
25:02
I can say that if we work out commission, then these benefits are bundled together because commission is worked out differently for different bundles. I can also say that a scenario is for a particular product, and that each product has its own commission scale.
25:20
There you know a lot more already, and you have an index that actually makes sense, an index that matches your understanding that you can use to navigate this code. One other quick example, just because people love to use inheritance in the wrong way. I have another client, they've got a system that has this clause called object table.
25:47
Now an object table is something that just displays a table on the screen for you, in which each row is an object and each column is an attribute of that object. And at some stage they had the need that people would have to filter this
26:02
thing, for example, maybe you just want to see the unit trusts that are actually active. And then they created object table with filter. And a little bit later on, someone had the need that you must also be able to filter these things by date, and so they added object table by date.
26:23
If you argue with someone about this, it's very difficult to say that these things aren't concepts. They are concepts. People with red shirt is also a concept, right? But is it a useful one? Does it say a lot about what's going on here? Or is it just an abuse of inheritance to reuse code?
26:45
There are other ways of doing this. For example, you could say let's change object table so that it actually has filters, and we introduce this new concept called filter. Then when we create an object table, we can decide if we want it to have filters or not and add the right ones.
27:02
Or you could say let's say we've got three objects, three kinds of things here, a report. So let's say an object table is just a simple table that displays stuff in a table. But a report is something that has filters and an object table, and it uses its filters to decide what gets displayed in the object table.
27:23
So there are lots of ways you can rig these things, and if you don't actually rig them to import meaning, that's when you run into problems. And that's what OO is all about. I prepared most of this talk from a book that is out of print.
27:42
You will still find secondhand copies of it on Amazon, I think. It's that book by James Martin and James O'Dell. I highly recommend it. If you want to know about good and bad design, I've worked for many years with the refactoring book next to your site. If you want to chat about this stuff, you're welcome to email me. You can even use our mailing list.
28:06
And then there's a link to all the slides. Thank you. Thank you very much. Any questions about object-oriented programming?
28:27
Thanks for the talk. It was great. If you were choosing a programming language to amplify this for students, would Python be the best choice?
28:48
I don't know about best. I really do like Python. I have to admit that because I have to make money, also I sometimes work with clients who do Java.
29:02
One nice thing about Java is that the refactoring tools work really, really well. Refactoring is a good way to learn about design because you see what's bad and you realize what can be better. To see the transformation in front of your eyes is really a good thing. I think it's a pity. We can actually do better.
29:22
The very first person who wrote his thesis on refactoring did it in Smalltalk with the same limitations we have in Python. I think even despite that I probably would still choose Python just because there's a lot less unnecessary fluff. And also because Python allows you to not always do everything in classes and methods.
29:43
If you just need a little function somewhere you can stick it in there. I think that helps as well. Any questions?
30:13
So Java for example offers you a lot of great tools for not only refactoring but expressing concepts.
30:21
And what I especially like about Java is the ability to define abstract classes and interfaces. Now I know that Python for example has introduced abstract base classes which in my opinion is a really valuable tool. But only during runtime, right? Because the implementation of ABCs is only validated during runtime.
30:41
So I was wondering, is there any tool that you can recommend to get a better understanding of the way classes interact even before you actually run the code in Python? I'm sorry, I'm not aware of anything. It's actually something I would really really like. I think the fact that Python is a dynamic language is something that means we have to deal with these things differently.
31:09
And how it was done before, long before in other languages, is to say well if you can use the trace functionalities and things to, if you run your tests, collect data about what calls what etc.
31:25
Then that gives you a lot of that static compile time information that you otherwise don't have in Python. And I actually really would love to see a tool that does that. And so that refactoring tools can be based off of that, but I'm not aware of anything like that.
31:48
Did you ever run into the problem that you had a concept that you could not realize with the programming language you chose and had to hack the concept or hack the programming language to make it actually work?
32:08
I'm gonna have to say no, but I probably cheated here and there. You know, nothing is perfect and the aim of this is not to have it perfect. The aim of it is just to help you have a good map of your code that works well with how our heads work.
32:25
And if you think about it, very very complicated things are expressed in terms of concepts if you think about Fourier transforms for example. It's a concept. But alright, no I haven't. But sometimes you cheat because remember classes aren't the only things that are concepts here.
32:47
The relationships are also concepts. The operations are also concepts. And sometimes you express a certain bit of information about something by adding a decorator to a method or whatever.
33:00
I think that we have enough play here to deal with everything that we need to deal with.
33:20
What's your opinion about duct-typing? Do you think it's a good design decision or something? I actually think it works quite well. I think that there are a lot of problems that Java for example run into with its interfaces. Because people create a lot of classes that don't really explain much.
33:44
They are very functional in name, like sortable. That doesn't tell me much. It just gives me the mechanics of making sure that this thing will work with other things. So I would actually prefer duct-typing over using abstract-based classes for example in most cases.
34:05
Thank you. We have one question from online. Craig asks, do students fresh out of university understand subject-oriented better than all the developers?
34:23
Do students still get taught object-oriented at universities? I don't know. This particular subject material, which is actually very theoretical, just gives you a different point of view on things, right?
34:43
But if I search on Google, I get encapsulation, inheritance, information hiding. It's almost like teaching someone how to drive a car by explaining how the car works. So I don't actually know. I don't have enough exposure to know what's being taught in universities currently.
35:01
But my feeling from where I stand is I miss these things. I don't see them around. When you have a lot of parent classes, when you're doing subtyping and whatnot, did you find a tool that could really easily debug, like if you have the same method in multiple parent classes,
35:23
sometimes you can get a conflict of methods, did you have a tool that could easily debug and see what is the order of execution? Because sometimes it's not really what you would want. Are you talking about having several sublet classes? Yes, if you have like one child built up from multiple, like with mixins or something like that.
35:45
Sometimes you get a conflict and you try to do your best to really separate this and not have these conflicts, but life happens. You know, I try to avoid mixins and multiple inheritance.
36:02
So, actually in our code base we have a couple of mixins in the test code, but I have come up with a plan to change that and I can't wait to be able to implement it. I think that multiple inheritance doesn't really add much to the picture. Usually you can actually express things differently by composing rather than inheriting, for example.
36:25
So, I haven't been searching for tools like that because I try just not to do it at all. It's actually a comment for your question. I don't know if this is what you're looking for, but I think that in Python 3, and I don't know if in Python 2, you actually have this magic parameter, object, method, resolution, or, yeah, MRO.
36:52
Under MRO, you have this and you can inspect it in a REPL session, actually, with your objects.
37:04
Just a brief other question. How about functional programming as an alternative? Because you've got closures and functions to be used rather than objects. Well, think about a function. A function can just be an implementation of an operation, right? And if you work with method, I don't know a lot of functional languages, but in Haskell, for example,
37:27
you can state what types a function is actually applicable to. You can have multiple functions with the same name, but expect different types. So, Haskell can actually also choose at runtime which actual implementation it will use.
37:44
So, I think that the same concepts apply. We have five minutes. Feel free to ask questions.
38:05
Well, if there are no questions, then I think that we could thank Simon for a great presentation.