Re: [boost] Preview 3 of the Geometry Library

Subject: Re: [boost] Preview 3 of the Geometry Library
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2008-10-16 18:23:12

Simonson, Lucanus J wrote:
>> My preference would be to have a circle data type, a sphere data type
>> and a hypersphere data type.  Only the hypersphere would be
>> parameterized on dimension.  The user would pick the object that is
>> named for what they want.  If a user wants a circle they are going to
be
>> frustrated and confounded that we provide them nsphere<2>.   There is
>> something of a conceptual disconnect between circle and sphere.

Steven Watanabe:
>What is wrong with
>    typedef nsphere<2> circle;

Nothing.

I'm not against saving typing with templates, I just don't want to do it
at the expense of readability and intuitiveness of the library API.
Some compilers will report the typedef name circle in errors and
warnings, while others will report nsphere<2>, which could hurt
readability of compiler errors.  Also, there is more at issue here than
what to name the geometry objects the library provides.  The more
important issue is whether there is a separate circle concept, sphere
concept and nsphere concept.  Circle and sphere could potentially be
related to nsphere in some manner, both circle and sphere might satisfy
nsphere, for instance, but not necessarily the other way around.  We
might use inheritance or specialization to produce a certain effect with
concepts.  Something that satisfies circle would also satisfy nsphere,
because circle could be derived from nsphere, but nsphere would not
satisfy circle unless it was 2D.

I was thinking something like the following might be a good idea:

template<int n>
struct hypersphere_concept {
...
};

struct sphere : hypershpere_concept<3> {
//optionally add stuff specific to sphere concept not applicable to
nsphere
...
};

struct circle : hypersphere_concept<2> {
//optionally add stuff specific to circle not applicable to nsphere
...
};

This general pattern should be applicable everywhere, and is similar to
what I'm doing with the generic geometry type system in my library.

Luke