[mercury-users] Wishes for 0.13.1

[Julien Fischer]

On Mon, 16 Oct 2006 doug.auclair at logicaltypes.com wrote:

> Dear Julien,
>
> If you will be adding rtree to 0.13.1 (which I hope you do, as I am now
> using it quite a bit), I have a small ordering request:  one of the provided
> types, box3d, has this ordering:

rtrees have now been added to the 0.13 branch - so they should appear in
0.13.1.

> box3d(xmin, xmax, ymin, ymax, zmin, zmax).
>
> I understand the implementation point, but, declaratively, it's weird.  I
> expected a box to be defined thus:
>
> box3d(xmin, ymin, zmin, xmax, ymax, zmax).
>
> and have run into logic errors in my programs when I trip up on my
> disconnect.

It makes sense to me: the first two coordinates specify the x dimension,
second two coordinates specify the y dimension, and so on.

If that arrangment is tripping you up then you could either:
(a) create your own box3d-like type that has the arguments around the way
     you want

or

(b) write a function that creates a box3d, like this:

 	create_box3d(XMin, YMin, ZMin, XMax, YMax, ZMax) =
 		box3d(XMin, Xmax, YMin, YMax, ZMin, ZMax).


> If there are no objections, could the definition of box3d be changed to the
> latter?  (The declaration is unchanged).

Either way is going to require you to remember what order the arguments
appear in - I guess it just a matter of taste but I don't really see
much point in changing it.

> If the same setup exists for the 'box' type, could the same implementation
> change occur?

The box (or is it box2d?) type is implemented in a similar fashion;
again I'm not inclined to change it.

Julien.
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users at csse.unimelb.edu.au
Administrative Queries: owner-mercury-users at csse.unimelb.edu.au
Subscriptions:          mercury-users-request at csse.unimelb.edu.au
--------------------------------------------------------------------------