3 ms·
> I’ll go out on a limb and posit that there are virtually no valid uses of (implementation) inheritance. class Iterable { ... } class Tree extends Iterab
by AdieuToLogic 5y ago
> I’ll go out on a limb and posit that there are virtually no valid uses of (implementation) inheritance.
class Iterable { ... }
class Tree extends Iterable { ... }
class SortedTree extends Tree { ... }
class Map extends Iterable { ... }
class HashMap extends Map { ... }
class InsertionMap extends Map { ... }
class BiMap extends Map { ... }
Need more examples of "valid uses of (implementation) inheritance"?
> And if you get rid of inheritance, there is very little left to distinguish OOP from procedural programming like one would do in C or Go.
No. To make OOP indistinguishable from "C or Go", you would also need to eliminate at least; encapsulation, composition, access control, and compiler provided dynamic dispatching.
- throwaway894345 5y ago> Iterable That’s easily achieved with plain interfaces. It’s not obvious to me at all why I would want to use inheritance instead of interfaces, especially because you elided the class bodies. > No. To make OOP indistinguishable from "C or Go", you would also need to eliminate at least; encapsulation, composition, access control, and compiler provided dynamic dispatching. C and Go have all of those things except that C doesn’t have “compiler provided dynamic dispatch” and I’m not sure how “access control” differs from “encapsulation” (access control is just public/private/etc, right?). * encapsulation: in C things in the header files are “public” while things in the c files are “private”. In Go we have private/public struct members. * composition: both C and Go have structs * compiler-provided dynamic dispatching: Go has interfaces and closures. C doesn’t have this provided by the compiler but you can implement them yourself easily enough. You lose out on some type safety, but that’s no worse than a dynamic OOP language and if you care about safety you probably aren’t using C anyway.