4 ms·
I know it isn’t really appropriate to the spirit of the article, but it seems like in this case there is a right answer, and it’s “Fully separate object types”
by joeatwork 3y ago
I know it isn’t really appropriate to the spirit of the article, but it seems like in this case there is a right answer, and it’s “Fully separate object types” - it’s explicit, prevents errors, is complete, and while it requires a lot of typing to implement it doesn’t require much complexity.
- ablob 3y agoIn which of the listed requirements of the article is this approach better, and why?
- joeatwork 3y agoI think it checks every box except “minimize the number of functions exposed”. Also, if your reasons for minimizing number of functions is about usability and complexity, then many functions that are all easily understood at once (and easy for the compiler to type check) might not substantially fail there either.
- cozzyd 3y agoYeah I agree. Macros can be used to avoid some of the typing in defining the interface when the implementation really is common, but unfortunately that makes it harder to document the generated interface. I wish doxygen had some way of supporting comments for macro-generated interfaces. In defining the implementation, it's easy enough to do something like this (if the implementation really is common): static int pdf_ll_foo_impl(pdf_ll_ctx_t c, pdf_ll_type_t t, ...) { //real implementation goes here, perhaps switching on t } int pdf_page_foo(pdf_page_ctx_t c, ..) { pdf_ll_foo_impl((pdf_ll_ctx_t) c, PDF_PAGE_TYPE, ..); } int pdf_pattern_foo (pdf_pattern_ctx_t c, ..) { pdf_ll_foo_impl(pdf_ll_ctx_t) c, PDF_PATTERN_TYPE, ..); } which you can also use macros to help generate if you want to.