[HOpenGL] Decoupling OpenAL/ALUT packages from OpenGL

Sven Panne Sven.Panne at aedion.de
Sat May 2 13:14:13 EDT 2009


I'd like to get some feedback from the Haskell community about some packaging 
issues, so here is my problem: As a medium-term goal, I'd like to decouple the 
OpenAL/ALUT packages from the OpenGL package, because there are very sensible 
use cases where you might need some sound, but not OpenGL. The current 
coupling has mostly historic reasons.

The OpenAL package depends on the OpenGL package in 3 areas:

   * OpenAL uses OpenGL's notion of StateVars all over the place.

   * OpenAL's Buffer and Source are instances of OpenGL's ObjectName class.

   * OpenAL's sources and listeners have some properties like velocity, 
orientation, direction and position which are modeled by OpenGL's Vector3 and 
Vertex3 data types.

The ALUT package depends on the OpenGL package because of GettableStateVars.

The packages are supposed to fit nicely together, so using the same types is a 
must, but the actual packaging is not nice. So the obvious idea is to 
introduce 3 new packages which lift out functionality from the OpenGL package:

   * a small "StateVar" package, consisting only of OpenGL's StateVar module 
(in a better place in the name hierarchy, of course, perhaps "Data.StateVar"?)

   * a tiny "ObjectName" package, consisting only of OpenGL's ObjectName class 
(In "Data.ObjectName"? I'm not very sure about a good place in the hierarchy 
here.)

   * a package containing most of the data types/newtypes in OpenGL's 
VertexSpec module (Vertex{2,3,4}, Color{3,4}, etc.) plus instances for the 
base classes like Eq, Ord, Show, etc. I really don't know a good name for this 
package and what a good place in the hierarchy would be (probably something 
like "Data.Foo", but what is Foo?)

The point is: The first two package would be very small. Would this be OK? 
Does anybody see other alternatives? What would be good names for those 
packages and where in the naming hierarchy should they really go?

Cheers,
   S.


More information about the HOpenGL mailing list