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

[Sven Panne]

Am Sonntag, 3. Mai 2009 00:56:00 schrieb Tillmann Vogt:
> Sven Panne schrieb:
> >    * 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.)
>
> How about Data.GraphicsObjects ? [...]

Thanks for all the suggestions so far, a few remarks from my side (I just 
picked the last mail for the reply, no strong reason for this...):

"Data.GraphicsObjects" is a bit misleading, because OpenAL's Buffers and 
Sources are instances, too, and they have nothing to do with graphics. 
Instances of ObjectName are just opaque resources from an external API, which 
you have to allocate and deallocate explicitly.

> I think it would be nice to have data types and functions for dot
> produkt, scalar product, norms, ...
> together with HOpenGL types.

I fear that this might open a can of worms and could lead to even longer 
discussions than the ones about a collection framework. The design space for a 
vector math package is quite large, and I fear that e.g. a mathematician 
trying to implement some linear algebra package has vastly different 
requirements than somebody trying to implement the n-th incarnation of the 
Quake engine. Some points to consider:

   * Should the components of vectors etc. be strict? In OpenGL they are, and 
Data.Complex is similar in this respect. In my experience non-strict 
components lead to space leaks too easily, and I guess this is the rationale 
behind Complex, too. But non-strict components have some benefits, too, of 
course, especially if you do symbolic computation.

   * Should we abstract over the number of dimension of vectors, etc.? If yes, 
how strong can our compile-time type checking be?

   * If we really make this a more general vector math package, things like 
colors etc. should probably stay in the OpenGL package. But there are a few 
other packages needing color data types, too...

   * If the package is not general enough, it might be a bad idea to steal 
names/hierarchy locations which *are* general.

Nevertheless, I'd be happy to see some proposals for a sensible, compact 
vector math package. Probably we can fulfill most of the common use cases with 
something simple.

And one word about lumping the 3 packages together: Any function, module, and 
package should have *one* clearly defined task, this is crucial for every SW 
design. I would have a hard time explaining what this "super package" is all 
about, even if we throw only 2 of the 3 packages together. Personally I feel 
that this is a strong argument for 3 separate packages.

> (I know that glu has tesselation). [...]

But GLU is basically dead with OpenGL 3.x. :-)

Cheers,
   S.