[simspark-devel] APL Design

[<ah...@un...>]

Hello,


After working with multiple inheritances for a day and a half, I ran into
new problems. Diamond Inheritances cause ambiguity problems due to
Zeitgeist's design, and after cutting some inheritances, it led to the
problem that some classes weren't derived from BaseNode anymore, and thus
lost the functionality of a SceneGraph Node that they need to have in
order to work. The ambiguity can be resolved with virtual inheritances,
but then you get trouble with boost's static casts if they find virtual
base classes down the line. Anyway, we had to come up with a new design
that fulfilled three requirements:

1) All classes that I want to create objects of must be derived from a
common base class, e.g. ODESphereCollider and BulletSphereCollider from
SphereCollider.

Necessary because calls like SphereCollider* soccerball = new
ODESphereCollider() must work.

2)  All classes that I want to create objects of, and the classes that
these classes are derived from, must be derived from BaseNode.

Necessary because the above mentioned ODESphereCollider must be added to
the SceneGraph, and many, many external classes expect classes like Body,
Collider or BallJoint to be derived from BaseNode.

3) When inheriting from multiple classes, the parent classes must not have
a common Base Class.

Necessary because of the ambiguity problems described above.

Some people were against sticking to the old design. Even if I use the new
design, I can still limit myself to the old functionality for the time
being and add all the new stuff (like SoftBodies) as empty placeholder
classes for the time being. When they're there, somebody can implement
them later.

We also looked at PAL. PAL uses virtual inheritances a lot to solve the
ambiguity problems. (Actually, PAL was what made us know that virtual
inheritances exist).

All this led to the rather unorthodox design you can see here:

http://www.uni-koblenz.de/~aheld/APL%20Design%20Sample.png

Note that this omits a great number of classes for the sake of readability.

The uncontinuous arrows denote that the child class will only inherit from
one of these. E.g. when ODE is used, Body gets derived from ODEBody, else
from BulletBody. The preprocessor will decide on that. The tasks of the
non-engine-specific classes, like Body and BoxCollider, is to pick the
correct base class, make sure that the leaf classes can inherit the proper
engine-specific code, and provide the SceneGraph-related functionality
that many external classes expect.

I hope that I finally found a design that will work, since I'm feeling
rather burned out. There are six DIN A4-sheets on my desk that all have
UML diagrams on them, as well a few xmi files on my computer :P

Like always, any objections/remarks are welcome.


thanks,

Andreas