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.