Documenting the classes PolyBase, Polyhedron and NNC_Polyhedron.

Hi all.
Now that we have merged the strict branch into the main one, we have to find a proper way of documenting classes PolyBase, Polyhedron and NNC_Polyhedron, as far as the "user" manual is concerned.
In _theory_, PolyBase is related to implementation and it should not appear in the user manual.
However, as things are now, almost all the methods are defined only in PolyBase and barely inherited by the two derived classes. This will be eventually solved by having both Polyhedron and NNC_Polyhedron inherit in a "protected" way from the base class and then populating the Polyhedron and NNC_Polyhedron classes of "using" directives (hoping that Doxygen will understand them). This way, topology mismatches will be detected at compile time.
Now, Doxygen has two configuration variables named INHERIT_DOCS and INLINE_INHERITED_MEMBERS. The following comes from the Doxygen manual:
================== INHERIT_DOCS If the INHERIT_DOCS tag is set to YES (the default) then an undocumented member inherits the documentation from any documented member that it reimplements. ================== INLINE_INHERITED_MEMB If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all inherited members of a class in the documentation of that class as if those members were ordinary class members. Constructors, destructors and assignment operators of the base classes will not be shown. ===================
These seems not enough for our goal, for 4 reasons:
1) I am not sure that Doxygen will interpret a "using" directive as the redefinition of a method, so that INHERIT_DOCS may not work;
2) according to the above explanation, INHERIT_DOCS works provided the underlying methods of the class PolyBase are _documented_, whereas in the user manual all "implementation" classes should NOT be documented.
3) Even if we avoid the above problems (e.g., by using the variable INLINE_INHERITED MEMBERS), we would end-up having all the methods documented twice, once in Polyhedron and once in NNC_Polyhedron.
4) It seems to me that protected methods are documented in any case, i.e., they are NOT affected by the HIDE_PRIVATE_MEMBERS variable.
Also, I cannot see handy alternatives. A possible solution is to have class PolyBase appear in the user manual and document all the common methods there. Also, to avoid spreading the documentation here and there, ALL the examples should appear in the detailed description section of the class PolyBase, included those examples that describe methods implemented in the derived classes, such as the constructors, the conversion functions mapping a Polyhedron into a NNC_Polyhedron and viceversa, and those few dedicated methods such as is_topologically_closed().
Is anyone foreseeing better alternatives ?
Enea.

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

On Wed, 27 Mar 2002, Roberto Bagnara wrote:
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:
- Rename Polyhedron to C_Polyhedron (from Closed Polyhedron).
- 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 know, I am far removed from the centre of things and don't hear all the reasons for why we do things as we do... But, it looks to me from here strange that we need this NNC_Polyhedron as a separate class from Polyhedron (was PolyBase). I had thought that the reason for having PolyBase was that it was in some way more general than an NNC_Polyhedron, but reading this, it is not so clear to me anymore. If a Polyhderon is not necessarily closed, it can be any Polyhedron?? On the other hand, a C_Polyhedron sounds like a subclass of the (NNC_)Polyhedron.
ciao, Pat
participants (3)
-
Enea Zaffanella
-
P M Hill
-
Roberto Bagnara