[PPL-devel] Another big change [Was: Documenting the classes PolyBase, Polyhedron and NNC_Polyhedron.]

[Roberto Bagnara]

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

-- 
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagnara at cs.unipr.it