I'm designing a C API which will have about a dozen getter functions for various values. Something like:
bool getSomeBool(); bool getSomeOtherBool(); ... int getSomeNumber(); int getSomeOtherNumber(); ...
This seems to me like a straightforward way to do it, easy to implement, easy to document, hard to use incorrectly.
However, in APIs like OpenGL, we encounter something like the following (simplified):
typedef unsigned int GLenum; bool glGetBool(GLenum pname); int glGetInteger(GLenum pname); #define GL_BLEND 0x0BE2 /* may be passed to glGetBool */ #define GL_ACTIVE_TEXTURE 0x84E0 /* may be passed to glGetInteger */
This has the obvious drawbacks that the enum value must match the function that it's being passed to, and that the enum value must be a valid enum value to begin with.
So surely, this approach must have some advantage too?
Extensibility comes to mind – we can now add new enum values without having to add new functions – but I don't see how that's any better than adding functions.