From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-12-21 06:10:47
Dave Harris wrote:
> In-Reply-To: <cpsv4p$foa$1_at_[hidden]>
> michaeltoksvig_at_[hidden] (michael toksvig) wrote (abridged):
>
>>you might consider adding operator[] to point and size
>>
>>also, consider defining area in terms of 2 points, and adding
>>operator[] to that, too
>
> I was about to say the same thing :-) I'd go further, and expose the
> array.
>
> class box {
> point data_[2];
> [snip]
> };
I think that this is the wrong representation.
> This is because you will almost certainly want transforms that act on
> arrays of points, and it will sometimes be convenient if they can act on
> rectangles too.
Translation: a.pos += gui::size( 5, 7 );
Scaling: a.size += gui::size( 10, 20 );
Rotation: n/a since you are assuming that each side has an angle of 90
degrees (allowing for two point representations).
> I would provide get/set methods which are independent of representation.
> I'd consider allowing things like ++box.top() too. Currently I think the
> convenience is not worth the loss of purity. ++box[0][1] should work,
> though.
If you have point high, low; then which corner is "high"? Likewise,
using top_left, bottom_right is bad. In general, storing a rectangle as
a set of two points is the wrong representation, especially for portability.
Windows defines (0, 0) to be the top left corner, while Mac/Cocoa define
it to be the bottom left corner. Therefore, in order to extract the two
points in any of the above point set representations, you need platform
dependant information about the coordinate orientation. This complicates
matters similar to my initial attempt (using properties) by having to
rely on platform dependant mapping every time you are referencing the
rectangle data.
Having a (point, size) notation, similar to the Cocoa representation,
you remove the need for platform dependancy (except when mapping between
the native type and the independant type). Also, this representation
simplifies translation and scaling (see above). You do not need to worry
about the direction of the size type since this is resolved for you by
the operating system. Granted, gui::rect( 10, 15, 100, 150 ) will be
orientated differently on Windows and Mac, but for the operating system
user, they will be orientated correctly.
> On naming... I think "area" is the wrong name.
I have revised the names for area (now rect with a typedef for rectangle
if you prefer to use the longer name) and position (now point).
> I see no benefit in using "position" instead of the usual "point". "Point"
> is shorter.
I was aiming at adding information to the name, for example
move( point pt ); // move to the new point
move( position pos ); // change the position
I have conceeded the point (pun intended!) and changed the name. It may
be a good idea to typedef point as position, like I do with rect.
> It's hard to improve on "size" :-)
:)
> I would seriously consider replacing float with a typedef, perhaps with
> another typedef for distances and offsets. Even without type checking, I
> think using more exact type names helps to clarify thought.
I am now using a UDT called metric (re: mathematics) to represent the
values. See the other messages in the thread for discussions on this.
> [Later...]
>
> I've looked at the code in the zip file now. I see it doesn't match the
> email. It uses a different representation and adds several member
> functions, although not as many as me. I am surprised to see things like
> size*size and size/size.
On review, I have removed size/size, size*size. As for the
representation change: this is an evolving library, but the essence
remains the same, so discussion here is still valid. I do not intend on
posting the full member function list as these e-mails are long enough
already! If you are interested, take a look at the code (as you have
done). I appreciate the feedback.
Regards,
Reece