Re: [boost] Re: thoughts on a GUI component library

From: Dave Harris (brangdon_at_[hidden])
Date: 2004-12-17 08:06:25

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];
    public:
        point *data() { return data_; }
        static size_t size() { return 2; }
        point &operator[]( size_t i ) { assert(i < 2); return data_[i]; }
        // Maybe begin/end too.
        
        const point &top_left() { return data_[0]; }
        const point &bottom_right() { return data_[1]; }
        float top() { return data_[0][1]; }
        float left() { return data_[0][0]; }
        float bottom() { return data_[1][1]; }
        float right() { return data_[1][0]; }
        size extent() const { return bottom_right() - top_left(); }
        float width() const { return right() - left(); }
        float height() const { return bottom() - top(); }
        point centre() const { return top_right() + extent()/2; }
        // ...
        void set_top_left( const point &p );
        void set_top( float f );
        void set_centre( const point &p );
        // ...
   };

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.

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.

On naming... I think "area" is the wrong name. To me an area can be any 
shape, or alternatively, every shape has an area. I would expect 
circle.area() to return pi*r*r. "Rectangle" is better, but what we 
actually have here is a special kind of rectangle which is aligned with 
the axis. A rotated rectangle needs more than 2 points. So conceptually we 
need two rectangle types. I suggest "rectangle" is reserved for the 
general case, and the aligned one is called "box". As in "bounding box". 
It has the benefit of being short.

I see no benefit in using "position" instead of the usual "point". "Point" 
is shorter.

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.

[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. 

I see the design is being driven by the needs of a windowing system, when 
I am being driven by the needs of a graphics/drawing system. That has led 
to different results, which I suspect is a bad thing. At any rate, it has 
convinced me that exposing raw member variables (like area.pos) is a 
mistake.

-- Dave Harris, Nottingham, UK