Give back multiple inheritance

[sgrantham at sympatico.ca]

I've just come across D and am impressed, although I think you (Digital Mar)
should have a comparison to Python as it would stack up against D much better
than the other languages.

I appreciate that the socialization of programming languages has driven the more
constrained approach to language structure in that the power of expression
within a language is traded off against, usefulness of expression, and the
ability of the inexperience to make a total mess (more power, more mess
potential).  However,  one of the more powerful and useful expression
capabilities of C++ is in multiple inheritance and its loss is to much of a
price.

I'll give an example in just a sec, but I want to dissuade those, whose
immediate reaction is: “Interfaces represent multiple inheritances”, from
thinking this.  If I define a class that includes multiple Interfaces, all that
I am doing is either: a) Informing the class user that the class will have a
certain behaviour (non-abstract class), which of course can be done as part of
the class definition, or informing the class deriver that they are going to have
to write a bunch of software every time they want to derive from the class.
Please don't make more work for me.  Write the software yourself.

This is not to take a way from Interfaces-- they have a purpose in stating that
a particular piece of software will have a certain behaviour, regardless of the
fact that the more object-like aspects of the software may not look much like
anything else.  They just don't represent multiple inheritance from any object
perspective.

I use the example of things organized in a tree because we have all suffered the
endless rounds of coding necessary to keep track of things in a tree collection
that is not the least bit necessary if multiple inheritance is in the picture.
I use the classic tree view of things in a PC (files, folders, devices, objects
identified by URLs, etc.)

I happened to have the following predefined (someone else’s) library of classes
for “File, “Folder”, “Device”, etc.  I also have a class named “Tree” which is
the standard implementation of a tree with the codicil that, knowing we have
multiple inheritance capabilities, we don’t have a separate class for a tree
node.  (A tree node is after all, just another tree).  So here’s how easy it is,
using multiple inheritance, to make our PC file type objects available for tree
operations.

class tFile : public File, Tree {};
class tFolder : public Folder, Tree{};
class tDevice : public Device, Tree{};

That’s it.  That’s all the code.  The only thing you might need to add is if you
need to relay constructors.  E.g.

class tFile : public File, Tree {tFile(string FileName) : File(FileName){};};

Now if the implementer of the Tree class has been smart the Tree definition has
been derived from a list definition (or a template).  For example:

class Tree : public LinkList  // pickup “Add”, “Remove” etc.
{
public:
Tree Parent;
void Add(Tree Item)  // Need to overload LinkList::Add
{
Item.Parent = this;
LinkList::Add(Item);
};

// class Tree::Enumerator

class Enumerator : private Tree, public LinkList::Enumerator 
{
// … 
// use link list enumerator but recurse through
// children
}
}

Isn’t all this so much easier?