I do not agree. Very often, when using libraries for example, you need some extra custom handling on types and data. So the easy way is to inherit and extend to a custom type while keeping the original functionality intact. The alternative is to place the new functionality in some unrelated place or create non-obvious related methods somewhere else. Which makes everything unnecessary complex.
And I think the trait system (in Rust for example) creates so much duplicate or boilerplate code. And in Rust this is then solved by an even more complex macro system. But my Rust knowledge might just nog be mature enough, feel free to correct me if I’m wrong…
So the easy way is to inherit and extend to a custom type while keeping the original functionality intact.
You can do this with traits and interfaces in rust/go. You can add any methods you want onto existing types. Which IMO is better. No need to subclass, in just just create a new trait, implement it on the type you want and you have new behavior attached to that type without needing to convert the existing thing you got from something into a new type.
And I think the trait system (in Rust for example) creates so much duplicate or boilerplate code.
It really does not. You can have implementation on traits that don’t need to be re-implemented on every type - like the Iterator - it provides 76 methods of which you need to implement only 1 for new types. You can implement others for custom behavior which is great for specialization (aka using a more efficient implementation for types that have more info, like calling skip on an array which knows all its elements vs the default which needs to call next n times).
But it creates a vastly more flexible system. Take a very basic example - read/writing to something. How do you model that with inheritance? Basically you cannot. Not without painting yourself into a corner eventually. For instance, you can read/write to a file, to a network socket, to stdin/stdout but each of these is very different. Stdin for instance cannot be written to and Stdout cannot be read from. You might want to have a buffered reader/writer as well that wraps these types making read operation cheaper.
You cannot put these into a inheritance tree. Everything either needs to inherit from the same generic base that can both read/write and probably also close. But then for some types you need to implement these methods that don’t make sense that do what? Nothing when called? or throw an exception? It is a poor way to model this behavior.
Read and Write are orthogonal ideas - they have nothing to do with each other except they might be useful on some of the same types. With interfaces/traits you are free to separate these and implement them on whichever types make sense for them.
I have not yet seen a problem that is solvable with inheritance that cannot be better solved with some other language feature in a better way. It sort of works for some things, but other solutions also work at least equally well. Which leave it in a state where what is the point of it? If it is not solving things better then other solutions we have these days?
I do not agree. Very often, when using libraries for example, you need some extra custom handling on types and data. So the easy way is to inherit and extend to a custom type while keeping the original functionality intact. The alternative is to place the new functionality in some unrelated place or create non-obvious related methods somewhere else. Which makes everything unnecessary complex.
And I think the trait system (in Rust for example) creates so much duplicate or boilerplate code. And in Rust this is then solved by an even more complex macro system. But my Rust knowledge might just nog be mature enough, feel free to correct me if I’m wrong…
You can do this with traits and interfaces in rust/go. You can add any methods you want onto existing types. Which IMO is better. No need to subclass, in just just create a new trait, implement it on the type you want and you have new behavior attached to that type without needing to convert the existing thing you got from something into a new type.
It really does not. You can have implementation on traits that don’t need to be re-implemented on every type - like the Iterator - it provides 76 methods of which you need to implement only 1 for new types. You can implement others for custom behavior which is great for specialization (aka using a more efficient implementation for types that have more info, like calling
skipon an array which knows all its elements vs the default which needs to call next n times).But it creates a vastly more flexible system. Take a very basic example - read/writing to something. How do you model that with inheritance? Basically you cannot. Not without painting yourself into a corner eventually. For instance, you can read/write to a file, to a network socket, to stdin/stdout but each of these is very different. Stdin for instance cannot be written to and Stdout cannot be read from. You might want to have a buffered reader/writer as well that wraps these types making read operation cheaper.
You cannot put these into a inheritance tree. Everything either needs to inherit from the same generic base that can both read/write and probably also close. But then for some types you need to implement these methods that don’t make sense that do what? Nothing when called? or throw an exception? It is a poor way to model this behavior.
Read and Write are orthogonal ideas - they have nothing to do with each other except they might be useful on some of the same types. With interfaces/traits you are free to separate these and implement them on whichever types make sense for them.
I have not yet seen a problem that is solvable with inheritance that cannot be better solved with some other language feature in a better way. It sort of works for some things, but other solutions also work at least equally well. Which leave it in a state where what is the point of it? If it is not solving things better then other solutions we have these days?
Yeah inheritance isn’t always the best solution. But even Java, the much maligned example for this, doesn’t do it for the i/o example you give.