[Haskell-cafe] Decoupling OpenAL/ALUT packages from OpenGL

[Peter Verswyvelen]

I think splitting this up is a good thing, and at first sight I thought it
was overkill to make 3 micro packages, but when thinking twice I believe it
is indeed the way to go:
- Having StateVar into its own module will hopefully promote its reuse by
other imperative wrapper libs which currently all have their own custom
code.

- I usually tend to rewrite my own strict vectors but I would prefer to
reuse the ones defined in OpenGL, so definitely these should go into a
package. It would also be nice to have another package that makes
Data.VectorSpace instances for each of these types. I have no idea about a
good package name :(

- I'm not sure about the ObjectName package, but it certainly does not
belong in any of the previous two packages, so it should go into another
package.

On Sat, May 2, 2009 at 7:14 PM, Sven Panne <Sven.Panne at aedion.de> wrote:

> 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.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090503/65b1dbaf/attachment.htm