[HOpenGL] Re: [Haskell] ANNOUNCE: OpenGLRaw 1.0.0.0

[Sven Panne]

Am Donnerstag, 11. Juni 2009 19:23:17 schrieb Bryan O'Sullivan:
> Since this is a new package, is there any possibility that the naming could
> be more economical?
>
> Graphics.Rendering.OpenGL.GL.CoordTrans is awfully long.
>
> I think that "Graphics.Rendering." is clutter, and "OpenGL.GL." seems
> redundant to me. I'd very much like to encourage the idea that tremendously
> long package names ought to be considered poor form.

While I consider this a bit long, too, there are a few reasons why it was done 
this way. The OpenGLRaw package exports 1025 functions, 1673 tokens and 20 
types, so one clearly needs some way of structuring this, the only question is 
how.

You rarely import on such a fine-grained level, most of the time you simply 
use the rather short

   import Graphics.Rendering.OpenGL

import, where you can even add "as GL" if you like for short explicit 
qualification later. Another example: If you explicitly only want to use pure, 
modern OpenGL 3.1 "the raw way", use:

   import Graphics.Rendering.OpenGL.Raw.Core31

If you additionally want to use the ARB_compatibility extension, use:

   import Graphics.Rendering.OpenGL.Raw.Core31
   import Graphics.Rendering.OpenGL.Raw.ARB.Compatibility

If you want the OpenGL 3.1 core plus all ARB extensions, use

   import Graphics.Rendering.OpenGL.Raw.Core31
   import Graphics.Rendering.OpenGL.Raw.ARB

And if you are very lazy, you can simply pull in the whole raw binding with

   import Graphics.Rendering.OpenGL.Raw

This leaves the decision about the granularity of the import to the user of 
the package, which is a good thing IMHO. The ".Raw" part is necessary to 
distinguish between the raw and the nice interface, leaving the dot out or 
replacing it with "_" wouldn't really buy us much.

One point here is debatable: Do we really need the ".Rendering" part in the 
package name or would simply "Graphics.OpenGL.Raw" be enough? We discussed the 
structure of the hierarchy when hierarchical packages were in their infancy, 
many years ago, and it was consensus then to distinguish between 
"Graphics.Rendering" and "Graphics.UI". I don't have very strong feelings 
about ".Rendering" and ".UI", and if the consensus nowadays is to remove it, 
I'll be happy to change this. But let's move the discussion about this to the 
libraries mailing list.

A few final remarks: Leaving out "Graphics." completely would be a very bad 
idea, the naming hierarchy should reflect the underlying conceptual hierarchy. 
The only problem with hierarchies in general is that sometimes the position in 
it is not very clear. I have e.g. never fully understood why "Monad" and 
"Applicative" are below "Control", but "Foldable" is below "Data"...

Cheers,
   S.