🚀 go-pugleaf

Proposal: Reconcile Inheritance and Inlining
--------------------------------------------
Rich Hickey
rich@rcs-hq.mhs.compuserve.com

Rationale:
----------

C++ suppports a powerful and flexible mechanism for inheritance, and for 
polymorphism via virtual functions.  It also supports the notion of 
inlining, which when used correctly can provide for execution speed as 
good as hand-written low-level code.  

Unfortunately, due largely to the way virtual functions are implemented 
(and I am not suggesting there is a better way to implement them), while 
virtual functions can be specified as inline, the vast majority of calls 
to virtual functions, i.e.  those through pointers or references, cannot 
be inlined.  

This has led developers to a distinct and rather arbitrary design 
decision - hierarchy and polymorphism vs. speed when using concrete 
classes, due largely to a mechanical language implementation artifact.  

In many cases where this decision is made, the hierarchical design takes 
the form of a tree of 100% abstract classes on inner nodes, with 
concrete classes occupying the leaf nodes.  In the non-hierarchical 
design there are concrete classes with inline functions, and no virtual 
functions.  In both cases the concrete classes represent the 
'end-of-the-line', and are not intended to be derived from.  

More often than not these days, the decision is made to abandon 
hierarchy so as to ensure optimal performance when manipulating the 
concrete classes.  Even those that treasure the performance possible 
with such designs are dismayed by the ease-of-use and flexibility lost 
in not being able to provide a hierarchy, particularly in building large 
systems where polymorphism is key to providing loosely-coupled 
architectures.

This prosposal sugggests a bridge that will support both hierarchy and 
inlining (in the context given above).  

-----------------------------------------------------------------------
I propose that the explicit keyword be allowed as a qualifier of a class 
definition, such qualification taking the form of:

explicit class X{
  //the definition of X
  };

and that such qualification has the following meaning:

For any class X defined as explicit -

X cannot be derived from.

Any calls to member functions of X, even through pointers or references 
to X, be called with the 'normal' function mechanism, i.e.  not the 
virtual function mechanism, as if the call took the form of 
x->X::function().  That is to say, all calls on X's are in the explicit 
scope of X.  (Language lawyers please refine)

Note that the explicit need only appear at the single  point of 
definition. This is not a type qualifier, and would _not_ appear 
anywhere else, in declarations, argument lists etc.

Example:

class B{
public:
   virtual int foo()const=0;
   //...
};

explicit class D:public B{
public:
  int foo()const{return data;}
  //...
private:
  int data;
};

void fred(const D &d)
   {
   d.foo();  //as if d.D::foo(); - inlined
   }

void ethel(const B &b)
  {
  b.foo();	//even if b is a D, virtual function call (as always)
  }

While the ban on derivation may seem draconian, it is hardly less 
extreme than saying - 'this design will have no hierarchy'. In any case 
the choice lies with the developer.

---------------------------------------------------------------
It is my (non-compiler/language developer) contention that this 
extension is trivial to specify and implement.

It cannot be otherwise accomplished in the language, i.e. it requires an extension.

It requires no changes to existing code.

Anyone not using it is unaffected by it.

It has no side-effects I have been able to think of.

It significantly enhances the language and the power and flexibility of 
developers using the language by reconciling 2 fundamental C++ idioms.

Rich





[ To submit articles: Try just posting with your newsreader.
		      If that fails, use mailto:std-c++@ncar.ucar.edu
  FAQ:    http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]