Re: [ocaml-opengl] [Caml-list] standard 3d vector library in OCaml

[Anthony Tavener <anthony.tavener@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3197 bytes --]

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.



On Fri, May 10, 2013 at 11:01 AM, Daniel Bünzli <daniel.buenzli@erratique.ch
> wrote:

>
>
> Le vendredi, 10 mai 2013 à 16:48, Florent Monnier a écrit :
>
> > A very good link, thanks a lot!
> > There's a huge amount of content, could you share which you think
> > would be the more interesting for reuse in OCaml?
>
> 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.
>
> > It seems logic to me to do it the way you've made it.
> > I would only comment that if you add Sizes, BBoxes, then why not also
> > bounding-cirlces / bounding-spheres, complete math for geometry with
> > points, lines, planes, etc. (distances, intersections, projections,
> > etc.)
>
> 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.
>
> > The internal representations for vectors and points are not public,
> > which would imply to integrate these inside your module.
>
> 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.
>
> > Maybe a compromise could be found,
> > between one letter function names:
> >
> > Size3.w
> > Size3.h
> > Size3.d
> >
> > and complete names:
> >
> > Size3.width
> > Size3.height
> > Size3.depth
> >
> > could be 3 letters abbreviations:
> >
> > Size3.wid
> > Size3.hei
> > Size3.dep
>
> 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.
>
> > I would recommend not to assume that everyone share the same cognition
> > and tastes than you.
>
> I certainly don't assume that. I do however program and design to my
> taste, not by consensus or compromise.
>
> Best,
>
> Daniel
>
>
> _______________________________________________
> OpenGL mailing list
> OpenGL@lists.ocaml.org
> http://lists.ocaml.org/listinfo/opengl
>

[-- Attachment #2: Type: text/html, Size: 4001 bytes --]