Subject: Re: [boost] A design for geometric objects
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2008-11-14 16:19:20
>> Wouldn't a typically C++-like approach be to use traits to ask each
>> shape to present itself as an ellipse if it can?
>> ellipse_traits<X>::get_length() and ellipse_traits<X>::get_width()
>> would give the length and width that X has when viewed as an ellipse.
>> ellipse_traits<ellipse> would simply define them as being its length
>> ellipse_traits<circle> would define them as both being its radius.
>> specialization ellipse_traits<rectangle> would not exist, meaning that
>> a rectangle is-not-an ellipse.
>> ellipse and circle would obviously be 2 completely separated classes.
>> Do you think this approach is valid and could be generalized to all
>> geometric shapes?
>Now you have way to state "X can be viewed as an ellipse". But how would
>you state "if X can be viewed as a circle, then it can be viewed as an
>ellipse (in the way that ellipse_traits<X>::get_width() returns
The approach is valid and could be generalized to all geometric shapes, but it is simply too labor intensive a proposition to implement all traits of all types that a given type could represent itself as. I am currently facing the problem that I am trying to overload every function for every valid conceptual type it can accept. This becomes a serious problem because it is very hard to implement a complete API and the work required simply to provide the functions I was getting for free through inheritance is leading to some significant code bloat. What we need is a 2nd level of abstraction. In addition to abstracting away the raw type of a geometric object we also need to be able to abstract away the conceptual type of a geometric object and write functions that work in terms of categories of conceptual types. For instance if there were some mechanism by which all rectangle, all flavors of polygon, any collection of polygons etc. could represent themselves as an iterator range over edges through a single template instantiation then a single implementation of perimeter would work on the whole phylogeny of piecewise linear 2d solid figures. That template when instantiated on a conceptually rectangle type would instantiate a template that depends upon only the rectangle traits provided for that type. In this way the user need only specialize the traits that pertain directly to their object type.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk