george's picture

Enum class

Hello, I was wondering why all the enums are defined within their own class?
Seeing as the names are guanteed to be unique why can't the enums be declared in the global OpenGL namespace? Or alternatively, if they have to go inside a separate scope, why can't the Enum class instead be a namespace?

Putting them inside a class of course forces people to write things like the following:
GL.Clear(GL.Enums.ClearBufferMask.COLOR_BUFFER_BIT | GL.Enums.ClearBufferMask.DEPTH_BUFFER_BIT);

which ends up longer than the equivalent Tao version:
Gl.glClear(Gl.GL_COLOR_BUFFER_BIT | Gl.GL_DEPTH_BUFFER_BIT);

albeit with a few less gls.

Personally, I'd ideally like to be able to write something like:
GL.Clear(ClearBufferMask.ColorBufferBit | ClearBufferMask.DepthBufferBit);

On a slightly related note, how come the enum values are still upper case? After all, you've removed the GL_ prefix, so why not go all the way and make them fit a bit more nicely with standard .NET names?

I realise I'm probably way too late to the discussion for any changes to be made, but I thought I'd mention it all the same.


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler.'s picture

Woah, lots of questions here! I'll start from the beginning:

[...] why can't the enums be declared in the global OpenGL namespace?
Two reasons: a) The OpenGL namespace would have to hold not only GL enums, but also GLU and GL3 (when it becomes available), and I wanted to avoid the possibility of clashes between GL and GL3 enums. b) Code-completion performance would take a big dive (I was experiencing 10+ second pauses each type I typed a dot).

Or alternatively, if they have to go inside a separate scope, why can't the Enum class instead be a namespace?
Because then you'd have to type the full path, e.g. "OpenTK.OpenGL.GLEnums". At least now there is a shortcut: "GL.Enums". While you could add a using directive for an enum, you wouldn't want to do it (due to the performance issues).

On a slightly related note, how come the enum values are still upper case? After all, you've removed the GL_ prefix, so why not go all the way and make them fit a bit more nicely with standard .NET names?
The reason is... well, I hadn't thought of that until you mentioned it! :) Yep, this is possible, indeed easy!, I'll try to add this capability to the generator for the next version.

I must admit you've piqued my curiosity. I'll try to generate an 'ideal' set of bindings following the template you mentioned above, and see how it works out. Now, I don't want to break everything by changing the interface yet again, but I was going to split OpenTK into two assemblies in any case (OpenTK.dll and OpenTK.OpenGL.dll), so tt won't be unreasonable to release two different OpenTK.OpenGL.dlls for compatibility reasons.

Have you noticed any other problems with the API? Because if yes, now would be a good to mention them!

george's picture

Ok, I hadn't thought of the code completion issue.
Final suggestion then, why not put them inside the GL class directly? At least then you'd get:

GL.Clear(GL.ClearBufferMask.COLOR_BUFFER_BIT | GL.ClearBufferMask.DEPTH_BUFFER_BIT);

which is a bit better, there's no chance of name clashes and code completion should be fast.

I'm really just poking through the API trying to decide whether to go with OpenTK or Tao. Atm I'm leaning towards OpenTK because I prefer the neatness over the straight C->C# feel of Tao.
Time permitting, I'm going to try and write a small windows forms app this week to get a better feel for it, so you may well hear more from me.