Enea Zaffanella wrote:
However, as things are now, almost all the methods are defined only in PolyBase and barely inherited by the two derived classes.
This fact should probably bring us to the next big change, which should go as follows:
1) Rename Polyhedron to C_Polyhedron (from Closed Polyhedron). 2) Rename PolyBase to Polyhedron.
Now C_Polyhedron and NNC_Polyhedron are just two varieties of Polyhedron, and we should probably insist they inherit _everything_ from Polyhedron (this means, e.g., implementing is_topologically_closed() in Polyhedron so that it does the right thing).
I see the following advantages:
- C_Polyhedron and NNC_Polyhedron have exactly the same interface, even though C_Polyhedron is an optimized version that only supports closed polyhedra.
- We can write "generic code" where the difference between C_Polyhedron and NNC_Polyhedron does now show up. For instance, we will not have to duplicate tens of functions in the C, Prolog and other languages' interfaces: we just differentiates on the constructors and share all the other code. In other words, we will have something like
ppl_new_C_Polyhedron and ppl_new_NNC_Polyhedron
but only one
ppl_Polyhedron_intersection_assign
that will work both on two C_Polyhedron and on two NNC_Polyhedron (and will give an error in all the other cases).
- End of the problems with doxygen, since the base class Polyhedron must go into the user's manual, since it details the common services provided by C_Polyhedron and NNC_Polyhedron.
What do you think? (I know, renaming PolyBase back to Polyhedron is a nuisance but this is better done in version 0.4 than 1.4 ;-) Ciao
Roberto