[joeatwork]

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.

[cozzyd]

Yeah 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.

[ablob]

In which of the listed requirements of the article is this approach better, and why?

[joeatwork]

I 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.