Inheritance was invented as a performance hack

Post by rectang » Fri, Apr 30, 2021, 3:57 PM UTC

valenterry wrote: post #47

After reading all the comments of many confused and curious, here is when inheritance is bad and why so _in the absence of any performance considerations_. First, inheritance from an interface/trait is totally okay. The problem is class inheritance, meaning implementation inheritance. There are two cases: 1) you inherit from a class and only add methods but don't overwrite anything. This is the good case, you can do…

    trait Stack {
        fn push(&mut self, element: i32);
        fn push_all(&mut self, all: Vec) {
            for element in all {
                self.push(element);
            }
        }
        fn pop(&mut self) -> Option;
    }

Post by Tyr42 » Fri, Apr 30, 2021, 4:14 PM UTC

rst wrote: post #184

dwattttt wrote: post #143

Earlier quoted context omitted.

You actually can have a single queue that handles the different cases. You want dynamic dispatch for that, the syntax looks like this (quick addition to the playground sample): https://play.rust-lang.org/?version=stable&mode=debug&editio...

... which does put both cars and bicycles in the same queue, but doesn't eliminate the copy-paste for each new type completely; 'car' and 'bicycle' still wind up with separate 'get_speed' impls, which are textually identical aside from the type names.

Post by [deleted] » Fri, Apr 30, 2021, 4:16 PM UTC

devit wrote: post #216

SMFloris wrote: post #122

Earlier quoted context omitted.

Recently experimented a bit with Rust and I found the reverse to be true. You cannot compose types in Rust. You compose behaviors not types. Very important distinction as I found out the hard way. Take the following example I have found on the net: https://play.rust-lang.org/?version=stable&mode=debug&editio... In that example, both the bicycle and the car have the property `speed`. Imagine you have multiple types no…

You can use a macro instead of copy and pasting. You can also do this: struct Vehicle { speed: f32, type: VehicleType } enum VehicleType { Car(...), Bicycle(...) } Or this (although this is the least common): struct Vehicle { data: VehicleData type: Box } struct VehicleData { speed: f32, } trait SpecificVehicle { fn quack(&self, data: &VehicleData); } impl SpecificVehicle for Car {...} impl SpecificVehicle for Bicycl…

Post by politician » Fri, Apr 30, 2021, 4:27 PM UTC

pierrebai wrote: post #209

d1plo1d wrote: post #200

Earlier quoted context omitted.

Very true. I'm checks cloc 14,000 lines into a personal project and I have yet to feel any need to use `dyn` (virtual dispatching for non-Rust folks).

"I've designed this project in Go following Go naturally imposed design patterns and found that I did not need inheritance.", said the Go programmer. "Well, mmm, duh?", thought programmers of other languages. "I've designed this project in Rust, following Rust-imposed design principles, and found monomorphism sufficient", said the Rust programmer. "Well, mmm, duh?", thought programmers of other languages. "I've desig…

Post by ncmncm » Fri, Apr 30, 2021, 4:39 PM UTC

zozbot234 wrote: post #140

ncmncm wrote: post #111

The original inspiration for the idea really has nothing whatever to do with its subsequent architectural role, nor with its value as a mechanism. As a performance optimization, inheritance demonstrated value at a time when performance improvements were at least three orders of magnitude more important than they are today. People here like to disparage OO and inheritance, but the distaste clearly is just a reaction t…

Implementation inheritance is indeed problematic, no matter how it's used. The defining feature of implementation inheritance is that any code, relating to any class in the hierarchy, can rely on methods that may then be overridden in unpredictable ways further down in the hierarchy. If you don't need or expect this behavior, you can use composition and delegation instead - which come with a far simpler semantics and…