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:<div><br></div><div>- Having StateVar into its own module will hopefully promote its reuse by other imperative wrapper libs which currently all have their own custom code.</div>
<div><br></div><div>- 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 :(</div>
<div><br></div><div>- 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.</div><div><br></div><div><div><div><div><div>
<div><div><div><div class="gmail_quote">On Sat, May 2, 2009 at 7:14 PM, Sven Panne <span dir="ltr"><<a href="mailto:Sven.Panne@aedion.de">Sven.Panne@aedion.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I'd like to get some feedback from the Haskell community about some packaging<br>
issues, so here is my problem: As a medium-term goal, I'd like to decouple the<br>
OpenAL/ALUT packages from the OpenGL package, because there are very sensible<br>
use cases where you might need some sound, but not OpenGL. The current<br>
coupling has mostly historic reasons.<br>
<br>
The OpenAL package depends on the OpenGL package in 3 areas:<br>
<br>
* OpenAL uses OpenGL's notion of StateVars all over the place.<br>
<br>
* OpenAL's Buffer and Source are instances of OpenGL's ObjectName class.<br>
<br>
* OpenAL's sources and listeners have some properties like velocity,<br>
orientation, direction and position which are modeled by OpenGL's Vector3 and<br>
Vertex3 data types.<br>
<br>
The ALUT package depends on the OpenGL package because of GettableStateVars.<br>
<br>
The packages are supposed to fit nicely together, so using the same types is a<br>
must, but the actual packaging is not nice. So the obvious idea is to<br>
introduce 3 new packages which lift out functionality from the OpenGL package:<br>
<br>
* a small "StateVar" package, consisting only of OpenGL's StateVar module<br>
(in a better place in the name hierarchy, of course, perhaps "Data.StateVar"?)<br>
<br>
* a tiny "ObjectName" package, consisting only of OpenGL's ObjectName class<br>
(In "Data.ObjectName"? I'm not very sure about a good place in the hierarchy<br>
here.)<br>
<br>
* a package containing most of the data types/newtypes in OpenGL's<br>
VertexSpec module (Vertex{2,3,4}, Color{3,4}, etc.) plus instances for the<br>
base classes like Eq, Ord, Show, etc. I really don't know a good name for this<br>
package and what a good place in the hierarchy would be (probably something<br>
like "Data.Foo", but what is Foo?)<br>
<br>
The point is: The first two package would be very small. Would this be OK?<br>
Does anybody see other alternatives? What would be good names for those<br>
packages and where in the naming hierarchy should they really go?<br>
<br>
Cheers,<br>
S.<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div><br></div></div></div></div></div></div></div></div>