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.