2016-01-10 21:56 GMT+01:00 Oliver Charles
I'm not really convinced by this. This change introduced an inconsistency and duplication, but doesn't really solve the problem. I already found another enum that has this problem (GL_LINEAR), and I hardly suggest introducing GL_LINEAR to work around that.
GL_LINEAR as a parameter is sometimes used as a GLenum (see e.g. glBlitFramebuffer) and sometimes as a GLint (see e.g. glGetTextureParameteriv), and there is no clear winner.
While I agree that OpenGL is barely typed *statically*, there is a lot of runtime type checking. In practice o always develop with KHR debug as an extension or replay via apitrace, and this always checks ebum values for validity.
Yes, using a debug context + glEnable(GL_DEBUG_OUTPUT_SYNCHRONOUS) + glDebugMessageCallback during development is always a good idea. Apart from the stateful nature of the API ("this and that is only allowed when we are in state foobar etc."), the whole notion of profiles and extensions makes it fundamentally impossible to have a 100% type-safe API. You can't even e.g. statically tell which set of enums is allowed as a parameter for a given function.
I think OpenGLRaw would be more practical with gl-style polymorphic patterns
As I said in my previous email: Whenever you use the OpenGL API directly (be it via OpenGLRaw or gl), you *will* have lots of 'fromIntegral's, and the patterns don't make much of a difference. A quick grep showed that your SSAO-example project has 33 fromIntegral calls, and only 2 are caused by the patterns being monomorphic. The luminance package is even more extreme in this respect: It contains 188 fromIntegral calls, and only 2 are caused by the monomorphic patterns. (I may be off by small amount, but that doesn't really change the fact.) So in a nutshell: This is a non-issue in practice and mostly a bikeshedding discussion, and I won't change that aspect of the binding. Cheers, S.