structs, classes, interfaces - Part III, Solution

[BCS]

Reply to Martin,

> The basic idea behind my solution is actually really simple. You just
> have to realize that (OOP-) inheritance as it is usually done is a 
> combination of two different concepts - composition and 
> polymorphism. What would happen if we disentangled these concepts?
> My suggestion would be to completely remove virtual functions from the
> language. Instead use interfaces to provide ad hoc runtime polymorphism.
> 

An interesting idea. However I agree that it's not likely to make it in. 
However another option that can be taken from the "oop is two things" standpoint 
is to allow composition in structs (the forthcoming "alias foo this;" gets 
much of that) You can already do this (I think) in a some what hackish manner 
in that you can treat a pointer to a struct as a pointer to the type of it's 
first member. A cleaner way to do things would be to allow a struct to inherent 
from another struct but with the restriction that the new struct can't override 
anything from the base struct and that casting to the derived type is an 
unsafe operation.

> Internally a pointer to an interface would actually be a struct
> containing the vtable and a pointer to the object which would be a
> tiny bit more costly than a class reference.
> 
>

I've wanted this for a LONG time. It would allow all sorts of fun things 
to implement an interface (functions, structs, maybe even basic types). Alas 
it would break COM or require a totally incompatible special case. (I darn 
to heck whoever defined the COM standard that way!)