3 ms·
What happens if library user wants to extend functionality? They can't inject their code into the library.
by 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 agoYeah, 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 agoBob 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 agoIf 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.