Personally, I hate hate hate C-ish libraries when a perlish approach fits much nicer. For example the OpenGL C libraries use something like hungarian notation so the caller can specify what types and how many parameters they pass in:
glGetLightfv glGetLightiv
These two functions make no sense in Perl, one is for passing in the number of the light as a floating point number, the other is for passing in the number as an integer number. So, conveniently, there is OpenGL::Simple, which exports only one function and uses Perl (or rather XS) code to determine which function was meant:
glGetLight
This is possibly slightly less efficient but doesn't burden me with thinking about the parameter count and types, especially when Perl has to convert to the right types anyway.
To answer your question, I like how you provide sensible defaults. You might want to make the other, more specialized C functions available too, but maybe not export them, so one can always still override your "smart" code. But as long as your "smart" wrapper even lives in Perl code, people can always look at it and patch it directly. So I say, go for it and reduce the API by Perl dwimmery ;-)
In reply to Re: Question about module interface style
by Corion
in thread Question about module interface style
by Leviathan
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |