42 ms·
OOP is a tool like any other, and it has real costs and benefits. The original idea of being able to easily add new common APIs via inheritance is very powerful
by thurn 3y ago
OOP is a tool like any other, and it has real costs and benefits. The original idea of being able to easily add new common APIs via inheritance is very powerful and widely applicable. In fact both Haskell and Rust wound up with a similar mechanism to inheritance (the 'deriving' annotation) to reduce the pain of problems like "I don't want to have to write code to define equality for every struct" which are hard for the purely-functional approach to solve.
- zaphar 3y agoNeither Haskell or Rust use inheritance for this though. They use Typeclasses or Traits respectively. Those have the nice property that they solve the specific problem of satisfying an interface for something without the accompanying problems of inheritance. Derive as an example doesn't use inheritance it uses code generation precisely because Rust wants to avoid inheritance. The key insight of eevee's article is that OO has succeeded mostly because bundling state and behavior together is a really useful way to structure your code and is the thing that you should leverage the most out of object oriented languages.
- bccdee 3y ago`derive` macros would not be possible to imitate with inheritance. `derive(PartialEq)`, for instance, examines all the fields of a struct definition and generates a function which compares them all. Using inheritance, you could inherit from a parent `PartialEquivalence` class, but if you added any new fields, you'd have to write your new implementation of the `==` operation by hand to accommodate them. Macros have a much longer history in purely functional languages (in particular, lisps) than they do in procedural or OO languages. So you could argue that this problem is actually much easier to solve from a functional approach.