 I'm a Solidity engineer at S-HOP and I'm here to quickly talk to you guys about composition over inheritance in Solidity. So quick intro, composition and inheritance came about at the advent of object oriented programming and graphical user interfaces. So in these, what about classes and objects and composition inheritance are how these classes and objects can talk to one another, how they can share code and so here's a quick bit of background about what each one is. Let's say I want to make a pizza. We have a pizza based class and it has a shape. We have a cheese class and it's got something about its flavor and we have a pepperoni class. Is that pepperoni spicy? We have another function. So when we then want to make a pizza we can either inherit all of the previous classes. The pizza and the pizza is a pizza based cheese and pepperoni and it automatically then gets all the information that the pizza based cheese and pepperoni got all into the new class. So the pizza is now the same shape as whatever it inherited. We can then use composition instead as our way of combining these three and so instead of inheriting them and automatically getting all of those functions it has variables. It has a pizza base, it has cheese and it has a pepperoni and if you want to find out if the pepperoni is spicy you look up the pepperoni and ask the pepperoni class. So that's just a quick background on what they are. Composition over inheritance was something introduced by the gang of four in 1994. Well they made the idea famous. They basically go through the idea that inheritance is essentially white box reuse of code. So when one class inherits another it can get all of the variables, it can see everything that's going on, all the computation, it can override functions and it's all then included in one class. Black box reuse is composition. So when two classes interact with one another you can't see what's going on inside the other class, you can't see how the answers are computed, you don't really care about how it's implemented, you can just interact with it, get the answers you need. They argue that this is far simpler, it doesn't matter how one thing is implemented as long as you know it's working. So along comes Ethereum and we have something called contract oriented programming. So it's very similar to object oriented programming but now we have a decentralized computer where instead of trusting a central party you have to trust that the smart contract really does what we think it does. So we also have the code publicly on chain which basically means you are asking people to hack you. So you really, really need to be able to look at that code and understand what it's doing. We also have gas costs but I'd say that the most important thing is readability. If you can't read the smart contract and you can't understand what it's doing you essentially have the same problems before it's happening, you really trust that it's going to work, how you think it's going to. This is a quote from I think the 1980s but it's feeling more relevant than ever in Ethereum that programs must be written for people to read. So in composition we have a separation of concerns. When you want to read a smart contract and argue about what it's doing you can read a smart contract separately, you can check in your head that that concern is doing what it wants to do and then only at the end do you then bring an integration testing and you then see how all the contracts talk to each other. But before that you can argue about them all individually and test them all individually. When we bring in inheritance to read one smart contract you have to jump between all the ones it inherits. You're trying to understand what it references a variable that you can't see and the one you're looking at, you then have to jump over to another contract, see that variable, see how it's been set up in another contract. And so you jump up and forth between other files and it's a lot more complex. Most importantly multiple inheritance can act very differently to how most people think it can and it's worked about before. So let's say we have this dev contract and we've got a function that says I'm a dev. We have a solidity dev and the talk function returns I write solidity and then calls it parent contract. I write solidity, I'm a dev, so it calls it back up to here. We have the same thing with a react developer, I write react I'm a dev and then we have Charlie and Charlie is a react developer and a solidity developer. Multiple inheritance of these two contracts. So to look at what Charlie returns when you call talk it obviously starts with that Charlie that's obvious but then what is super.talk? What does it call up to? Which parent contract? Hard to tell. In solidity it calls up to the solidity developer and it comes out with I write solidity and that one calls super.talk from there but instead of calling the developer one which you'd think from solidity dev it actually jumps back down to the react developer and outputs I write react and then from there it finally calls back up to the top and you can see how that's an unexpected thing but it's not just in solidity it happens in other object oriented programming languages as well but you can easily see how bugs might come in there. It's very hard to read what sort of chain is going to follow. So it's not all bad it's how we ran standards. Also people inherit the LC20 contracts for example to have the LC22 opens people inherit earnable, pausable, the opens up in contracts to and they're great lifecycle things that you can implement in your smart contracts to keep them safe but there's definitely complications when you're doing it and you have to really know what you're doing to make sure these bugs don't occur. So gas is also a consideration one contract is cheaper than two but if you're just deploying contracts once is it really worth saving $10 just to have slightly more complex contracts. Immutability upgrading is easier if you have composition but people don't like upgradeability necessarily either so that's a subject for another talk. Thank you very much is my contact details with you.