<div dir="ltr">I've found that using a module prefix in combination with short (single letter) labels in mathematical contexts works very well. It strikes a balance of succinctness-in-use with enough verbosity to establish context. So I like Daniel's field names. :) They also correspond to shading language field designations. Before local module-opens I would avoid such names because opening more than one module would almost guarantee a conflict. Now I only open a few "prevasives"-like modules and use local-opens liberally.<div>
<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 10, 2013 at 11:01 AM, Daniel Bünzli <span dir="ltr"><<a href="mailto:daniel.buenzli@erratique.ch" target="_blank">daniel.buenzli@erratique.ch</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Le vendredi, 10 mai 2013 à 16:48, Florent Monnier a écrit :<br>
<div class="im"><br>
> A very good link, thanks a lot!<br>
> There's a huge amount of content, could you share which you think<br>
> would be the more interesting for reuse in OCaml?<br>
<br>
</div>I think each of them serve different purpose (e.g. computational trade-offs on embedded platforms) that's the reason why these things are best left outside gg for now.<br>
<div class="im"><br>
> It seems logic to me to do it the way you've made it.<br>
> I would only comment that if you add Sizes, BBoxes, then why not also<br>
> bounding-cirlces / bounding-spheres, complete math for geometry with<br>
> points, lines, planes, etc. (distances, intersections, projections,<br>
> etc.)<br>
<br>
</div>I don't plan to integrate these things, no pull requests please. At a certain point I was planning to but it was becoming unwieldy -- remnant of these ideas can be seen in the tmp/ directory of the first commit. Gg provides you with the essentials to do 2D or 3D computer graphics. Sizes and rectangles are ubiquitous: viewports, image extents, etc. and that's the reason they are in. More general computational geometry tools are best left to another dedicated library.<br>

<div class="im"><br>
> The internal representations for vectors and points are not public,<br>
> which would imply to integrate these inside your module.<br>
<br>
</div>Regarding the internal representation I still have to think about what I will do. Gg is designed to interoperate with C so that means that the representation will be cast in stone anyways.<br>
<div class="im"><br>
> Maybe a compromise could be found,<br>
> between one letter function names:<br>
><br>
> Size3.w<br>
> Size3.h<br>
> Size3.d<br>
><br>
> and complete names:<br>
><br>
> Size3.width<br>
> Size3.height<br>
> Size3.depth<br>
><br>
> could be 3 letters abbreviations:<br>
><br>
> Size3.wid<br>
> Size3.hei<br>
> Size3.dep<br>
<br>
</div>Well, no… it's horrible to read, hard to remember and inconsistent: if you look at all the other vector types in Gg their coordinate accessors all have a single letter V2.{x,y}, P2.{x,y}, V3.{x,y,z}, P3.{x,y,z}, V4.{x,y,z,w}, Color.{r,g,b,a}, Quat.{x,y,z,w}. Having Size2.{w,h} and Size3.{w,h,d} feels natural.<br>

<div class="im"><br>
> I would recommend not to assume that everyone share the same cognition<br>
> and tastes than you.<br>
<br>
</div>I certainly don't assume that. I do however program and design to my taste, not by consensus or compromise.<br>
<br>
Best,<br>
<br>
Daniel<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
OpenGL mailing list<br>
<a href="mailto:OpenGL@lists.ocaml.org">OpenGL@lists.ocaml.org</a><br>
<a href="http://lists.ocaml.org/listinfo/opengl" target="_blank">http://lists.ocaml.org/listinfo/opengl</a><br>
</div></div></blockquote></div><br></div>