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

From: Aaron W. LaFramboise (aaronrabiddog51_at_[hidden])
Date: 2004-12-16 23:06:56

Andy Little wrote:
> "John Torjo" <john.lists_at_[hidden]> wrote

>>As a side-node, I'm moderately against having float coordinates. Why would
>>you think int is not enough?

> A more complete framework would have UDT's rather than ints, representing
> pixels, as well as other types representing inches, millimetres  as used in
> (say) CSS and (I think) SVG etc, which would allow automatic conversion
> (runtime for  pixels) of one measure to another. It would also allow precise
> control over the semantics of converting.

Is there a compelling reason for specifying an arithmetic type for
coordinates?

Or put another way, is there a disadvantage to leaving the coordinate
type entirely opaque?

A related situation from another problem domain is the time_t.  While it
is specified to be arithmetic, it may as well be opaque, as its
representation is unspecified.  In retrospect, would requiring it to be
a particular type or representation been beneficial?  Note that the
return type of difftime() is double.

The STL is another source of experience, where nearly everything is of
an unspecified type, and often unspecified representation.  In general,
I think this vagueness in specification has led to a flexability that
gives C++ a unique advantage over other similar languages.

The recently reviewed conversions library also may be a useful source of
experience with regards to this issue.

I think the decision on the representation of coordinates is an
extremely important one--one that might doom a library to ultimate
obsoletion if decided wrongly.  As Boost is meant to be a model of _the
C++ way_, future libraries may also be inclined to specify in the manner
Boost does.  It's very important to remain forward-looking, thinking
not, "What sort of pixel representation do today's GUIs use?" but rather
"Will tomorrow's GUI be based on pixels?"

Aaron W. LaFramboise