3 ms·

>What? Using multiple inheritence? You just threw this in out of nowhere. I didn't mention anything about "multiple" inheritance. Just inheritance which by def

>What? Using multiple inheritence? You just threw this in out of nowhere. I didn't mention anything about "multiple" inheritance. Just inheritance which by default people usually mean single inheritance. That being said multiple inheritance is equivalent to single inheritance of 3 objects. The only problem is because two objects are on the same level it's hard to know which property overrides which. With a single chain of inheritance the parent always overrides the child. But with two parents, we don't know which parent overrides which parent. That's it. But assume there are 3 objects with distinct properties. A -> B -> C would be equivalent to A -> C <- B. They are isomorphic. Merging distinct objects with distinct properties is commutative which makes inheritance of distinct objects commutative. C -> B -> A == A -> B -> C >I've been programming for 30 years and I've still never seen an example of multiple inheritance that hasn't eventually become a source of regret. Don't ever tell me that programming for 30 years is a reason for being correct. It's not. In fact you can be doing it for 30 years and be completely and utterly wrong. Then the 30 years of experience is more of a marker of your intelligence. The point is YOU are NOT understanding WHAT i am saying. Read what I wrote. The problem with inheritance has to do with human capability. We can't handle the complexity that arises from using it extensively. But fundamentally there's no OTHER SIMPLER way to merge two objects without resorting to complex nesting. Think about it. You have two classes A and B and both classes have 90% of their properties shared. What is the most fundamental way of minimizing code reuse? Inheritance. That's it. Say you have two structs. The structs contain redundant properties. HOW do you define one struct in terms of the other? There's no simpler way then inheritance. >> Composition is often more appropriate than inheritance. You can use composition but that's literally the same thing but wierder, where instead of identical properties overriding other properties you duplicate the properties via nesting. So inheritance A = {a, b}, C = {a1}, A -> C = {a1, b} Composition: A = {a, b}, C = {a1}, C(A) = {a1, {a, b}} That's it. It's just two arbitrary rules for merging data. If you have been programming for 30 years you tell me how to fit this requirement with the most minimal code: given this: A = {a, b, c, d} I want to create this: B = {a, b, c, d, e} But I don't want to rewrite a, b, c, d multiple times. What's the best way to define B while reusing code? Inheritance. Like I said the problem with inheritance is not the concept itself. It is human nature or our incapability of DEALING with the complexity that arises from it. The issue is the coupling is two tight so you make changes in one place it creates an unexpected change in another place. Our brains cannot handle the complexity. The idea itself is fundamental not stupid. It's the human brain that is too stupid to handle the emergent complexity. Also I don't give two flying shits about google style guides after the fiasco with golang error handling. They could've done a better job.

matkoniecz 1y ago
> Say you have two structs. The structs contain redundant properties. HOW do you define one struct in terms of the other? There's no simpler way then inheritance. why inheritance would make it easier?
- ninetyninenine 1y ago
  I have: A = {a, b, c, d, e} I want to write: B = {a, b, c, d, e, f, g} But I don't want to write duplicate code So I write: B = B(A) = {A, e, f, g} aka I use inheritance. Are there easier ways? No. Inheritance is the most fundamental way of doing this. Composition is just a work around as it results in arbitrary nesting. But ultimately it's the same thing too.
josephg 1y ago
> But assume there are 3 objects with distinct properties... Why would we assume that? If the objects are entirely distinct, why are you combining them together into one class at all? That doesn't make any sense. Let distinct types be distinct. Let consumers of those types combine them however they like. > But fundamentally there's no OTHER SIMPLER way to merge two objects without resorting to complex nesting. [...] You have two classes A and B and both classes have 90% of their properties shared. What is the most fundamental way of minimizing code reuse? Inheritance. That's it. So now the objects have 90% of their properties shared. That's different from what you were saying earlier. But moving on... The composition answer is similar to the inheritance answer. Take the common parts and extract them out into a self contained type. Use that type everywhere you need it - eg by including it in both A and B. > given this: A = {a, b, c, d} I want to create this: B = {a, b, c, d, e}. [...] What's the best way to define B while reusing code? Via composition, you do it like this: B = { a: A, e } What could be simpler than that? You keep claiming that inheritance is simpler. But then you go on to say this: > The problem with inheritance has to do with human capability. We can't handle the complexity that arises from using it extensively. [..] It is human nature or our incapability of DEALING with the complexity that arises from it. The issue is the coupling is two tight so you make changes in one place it creates an unexpected change in another place. Our brains cannot handle the complexity. In other words, using inheritance increases the complexity of the resulting code for the human brain. It makes our code harder to read & understand. I absolutely agree with this criticism you're making. And that's an incredibly damning criticism, because complexity is an absolute killer. Your capacity to wrangle the complexity of a given piece of code is the single greatest limitation of any software developer, no matter how skilled. Any change that makes your code more complex and harder to understand must be worth it in some way. It must pay dividends. Using inheritance brings no benefit in most cases over the equivalent compositional code. The only thing that happens is that - as you say - it makes the software harder for our brains to handle. If you ask me, that's a terrible decision to make.

matkoniecz 1y ago

> Say you have two structs. The structs contain redundant properties. HOW do you define one struct in terms of the other? There's no simpler way then inheritance. why inheritance would make it easier?

ninetyninenine 1y ago
I have: A = {a, b, c, d, e} I want to write: B = {a, b, c, d, e, f, g} But I don't want to write duplicate code So I write: B = B(A) = {A, e, f, g} aka I use inheritance. Are there easier ways? No. Inheritance is the most fundamental way of doing this. Composition is just a work around as it results in arbitrary nesting. But ultimately it's the same thing too.

josephg 1y ago

> But assume there are 3 objects with distinct properties... Why would we assume that? If the objects are entirely distinct, why are you combining them together into one class at all? That doesn't make any sense. Let distinct types be distinct. Let consumers of those types combine them however they like. > But fundamentally there's no OTHER SIMPLER way to merge two objects without resorting to complex nesting. [...] You have two classes A and B and both classes have 90% of their properties shared. What is the most fundamental way of minimizing code reuse? Inheritance. That's it. So now the objects have 90% of their properties shared. That's different from what you were saying earlier. But moving on... The composition answer is similar to the inheritance answer. Take the common parts and extract them out into a self contained type. Use that type everywhere you need it - eg by including it in both A and B. > given this: A = {a, b, c, d} I want to create this: B = {a, b, c, d, e}. [...] What's the best way to define B while reusing code? Via composition, you do it like this: B = { a: A, e } What could be simpler than that? You keep claiming that inheritance is simpler. But then you go on to say this: > The problem with inheritance has to do with human capability. We can't handle the complexity that arises from using it extensively. [..] It is human nature or our incapability of DEALING with the complexity that arises from it. The issue is the coupling is two tight so you make changes in one place it creates an unexpected change in another place. Our brains cannot handle the complexity. In other words, using inheritance increases the complexity of the resulting code for the human brain. It makes our code harder to read & understand. I absolutely agree with this criticism you're making. And that's an incredibly damning criticism, because complexity is an absolute killer. Your capacity to wrangle the complexity of a given piece of code is the single greatest limitation of any software developer, no matter how skilled. Any change that makes your code more complex and harder to understand must be worth it in some way. It must pay dividends. Using inheritance brings no benefit in most cases over the equivalent compositional code. The only thing that happens is that - as you say - it makes the software harder for our brains to handle. If you ask me, that's a terrible decision to make.