Cool thing about D, number #72

[Daniel Keep]

Bill Baxter wrote:
> I've always had this dilemma in C++ when writing graphicsy methods,
> whether a function that takes a point should take separate components
> (float,float,float) or a vector (Vec3f), or perhaps a pointer (float*).
>  In D there's also the option of float[3].  Or just for convenience sake
> maybe overloads for all of the above.
> 
> I just realized today the coolness of tupleof for this kind of
> situation.  You can make the function takes the plain floats
> 
>    do_something_at_point(float x, float y, float z);
> 
> And still call it using a Vec3f via tupleof!
> 
>    Vec3f world_origin;
>    ...
>    do_something_at_point(world_origin.tupleof);
> 
> as opposed to
> 
>    do_something_at_point(
>        world_origin.x,
>        world_origin.y,
>        world_origin.z);
> 
> It's a minor thing, but it rocks.
> 
> 
> --bb

I discovered the same thing, by roughly the same thinking.  I was
working with DFL and cairo, and was using DFL's color structure.
Problem was that DFL's stored using ubytes, and I wanted doubles.

So when I was writing my own colour structure, as I was defining the
storage, I wrote

> union
> {
>     struct { double r, g, b, a; }
>     double[4] rgba;
> }

And it suddenly hit me: I could add a tuple!

Now, I have .tuple members for my colour structs, vectors, quaternions,
matrices, and just about every other aggregate type I've written.

One thing that would make this an order of magnitude more useful would
be the ability to return a tuple from a function.

But I agree: it's cool :)

	-- Daniel

P.S.  I use .tuple instead of .tupleof because I don't want to shadow
the very-useful compile-time property :)

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/