> Rather than forcing the user to manually convert their data types to some Polyscope types, we implement a series of templated adaptor functions, which attempt to read from the user types via a common set of strategies. These adaptors are applied to the inputs to nearly all Polyscope functions, allowing them to automatically accept user-defined types as inputs.
It's interesting how object oriented programming seems entirely orthogonal to code reuse. Polyscope seems to have solved that problem with templates, but I wonder what the compilation errors will look like if your type does not support one of the required operations. Would Concepts finally solve this problem in C++20?
Anecdotally, message-passing OO style is great for code reuse where there's a lot of state to manage - you tie together the state and the functions that operate only on that state, and you get a nice clean reusable module. Inheritance-style, however, I've never found especially useful - it seems like the layers just end up depending on each other in an opaque fashion.
Polyscope, however, seems sufficiently ambitiously abstract that "code reuse" might be too narrow of a concept. It's a great example of the fuzzy distinction between "writing a library" and "inventing a DSL".
3 comments
[ 3.0 ms ] story [ 17.1 ms ] threadIt's interesting how object oriented programming seems entirely orthogonal to code reuse. Polyscope seems to have solved that problem with templates, but I wonder what the compilation errors will look like if your type does not support one of the required operations. Would Concepts finally solve this problem in C++20?
Polyscope, however, seems sufficiently ambitiously abstract that "code reuse" might be too narrow of a concept. It's a great example of the fuzzy distinction between "writing a library" and "inventing a DSL".