6 ms·

Many languages provide unions or sum types along with exhaustiveness checking to make this very easy (frequently not OO-inheretence based languages though).

Ygg2 4y ago
What happens if library user wants to extend functionality? They can't inject their code into the library.
- deleted 4y ago
  [deleted]
- piaste 4y ago
  Yeah, it's very awkward. Your best option is to leave a 'hole' case where someone may provide a 'data type' set of functions satisfying an interface, and the library author simply calls them. Effectively you're adding an OO escape clause, but it's ugly and will break user code when you add more functions and grow the interface. Conversely, in a codebase organized by objects it's not clean to add an extra method to the base class and each subclass. You have to write an external function and switch over every known subclass inside it, which is also very ugly and will also break when you add more subclasses. The two designs are actually the duals of each other. Someone compared it to rows vs columns and it's a great comparison. In OO, the methods are columns and each new row is a new subclass implementing them. In FP, the types are the columns and each new row is a function that switches over the possible types.
  - sarchertech 4y ago
    Bob Nystrom has a good article on this (the expression problems it’s called) https://journal.stuffwithstuff.com/2010/10/01/solving-the-expression-problem/ https://journal.stuffwithstuff.com/2010/10/01/solving-the-ex... He also discusses it in his book Crafting Interpreters.
- Olreich 4y ago
  If this is going to be a library where that’s a desirable feature, architect it for that feature. In the example, one easy way would have the coefficient table be expandable/replaceable. If you really need to run arbitrary user code, then write an interface that the user will conform to and call their code. You don’t even need OOP support to do that easily, just typed function pointers.
crabbone 4y ago
Why would you go with "many languages" into a thread showcasing how C++ sucks? I'm pretty sure that had the author of the video done all the same manipulations in Python, the speed difference would've been negligible. The author of the video discovered that C++ compiler is dumb when it comes to optimizing virtual method calls (that instead of bare virtual method calls he had to help the compiler to guess the right conditions where these virtual calls could be replaced with guessed static calls). Essentially, all that his video is saying is: "virtual calls bad if-else good". Which is like what every C++ game-dev thinks after few years on the job. Which is amusing in how short-sighted it is, and sometimes even more amusing to discover the "solutions" created by such C++ game-devs that are aimed at replacing C++ objects, but do it in a way that's even worse than C++ original design (who would've thought that to be possible!?)

Ygg2 4y ago

What happens if library user wants to extend functionality? They can't inject their code into the library.

deleted 4y ago
[deleted]
piaste 4y ago
Yeah, it's very awkward. Your best option is to leave a 'hole' case where someone may provide a 'data type' set of functions satisfying an interface, and the library author simply calls them. Effectively you're adding an OO escape clause, but it's ugly and will break user code when you add more functions and grow the interface. Conversely, in a codebase organized by objects it's not clean to add an extra method to the base class and each subclass. You have to write an external function and switch over every known subclass inside it, which is also very ugly and will also break when you add more subclasses. The two designs are actually the duals of each other. Someone compared it to rows vs columns and it's a great comparison. In OO, the methods are columns and each new row is a new subclass implementing them. In FP, the types are the columns and each new row is a function that switches over the possible types.
- sarchertech 4y ago
  Bob Nystrom has a good article on this (the expression problems it’s called) https://journal.stuffwithstuff.com/2010/10/01/solving-the-expression-problem/ https://journal.stuffwithstuff.com/2010/10/01/solving-the-ex... He also discusses it in his book Crafting Interpreters.
Olreich 4y ago
If this is going to be a library where that’s a desirable feature, architect it for that feature. In the example, one easy way would have the coefficient table be expandable/replaceable. If you really need to run arbitrary user code, then write an interface that the user will conform to and call their code. You don’t even need OOP support to do that easily, just typed function pointers.

crabbone 4y ago

Why would you go with "many languages" into a thread showcasing how C++ sucks? I'm pretty sure that had the author of the video done all the same manipulations in Python, the speed difference would've been negligible. The author of the video discovered that C++ compiler is dumb when it comes to optimizing virtual method calls (that instead of bare virtual method calls he had to help the compiler to guess the right conditions where these virtual calls could be replaced with guessed static calls). Essentially, all that his video is saying is: "virtual calls bad if-else good". Which is like what every C++ game-dev thinks after few years on the job. Which is amusing in how short-sighted it is, and sometimes even more amusing to discover the "solutions" created by such C++ game-devs that are aimed at replacing C++ objects, but do it in a way that's even worse than C++ original design (who would've thought that to be possible!?)