Multiple alias this, what's the hold up?

[Ethan]

On Sunday, 16 June 2019 at 06:08:54 UTC, Walter Bright wrote:
> Multiple alias this is multiple inheritance. Generally, if you 
> find yourself wanting multiple inheritance, it's likely time to 
> rethink the data structures.

I'm going to voice up for the "not generally" case.

Other people have made the point about casting to the internal 
type, and I've certainly used that to simulate value-type 
inheritance for C++ interop (see the talks I did at DConf 2016 
and 2017; and more recently, Manu requesting struct inheritance 
for this very purpose).

But that's not the point I want to make.

The games industry was slow to adopt object-oriented programming 
solely because of the performance implications in compilers at 
the time. It was really only in the Playstation 2 era that C++ 
became the de facto standard.

And just as quickly, we started realising object oriented 
programming wasn't all it was cracked up to be.

One example I always bring up here is a PS2 game that Manu and I 
are credited on. We had friendly characters that would stand 
around and respond to the player character whenever interacted 
with, usually to give out missions and rewards. The hierarchy to 
get this working was something like:

* MKProp - Base level engine functionality for game objects.
* KDProp - An extended library that added common game 
functionality that fell outside of pure engine code.
* KDPropEx - An extension that introduced a component object 
system.
* DynamicProp - The first level in the hierarchy actually in game 
logic, included collision objects for dynamic simulation purposes.
* Character - Now with animation and a few other things that 
general humanoid objects would use.
* Friend - As opposed to the Enemy object, a bunch of routines 
for friendly characters and making sure there was no way to 
actually kill them for example.
* IdleFriend - Turns almost everything about a 
Friend/Character/DynamicProp/KDPropEx/KDProp/MKProp off solely to 
make a static friendly character that you could talk to.

...yeah. That is bonkers.

The solution we've been settling on for a while is already hinted 
to above. Component object systems. The idea being that we take 
discrete chunks of logic and encapsulate them in one object. So a 
visual mesh is one component. Collision. Animation systems. So on 
and so forth. You define an object by what it uses, not where it 
fits best in an object hierarchy.

Doing it this way is easier to maintain and heavily promotes code 
re-usability. It also means you define new game object types with 
data rather than with code. But there are some costs. Your game 
object stops being something you can cast up and down a 
hierarchy, instead you have to query objects for the existence of 
a component that you're interested in. That's a runtime cost, 
usually a map lookup of some sort.

Perhaps you can already see where I'm going here.

The C++ and C# systems that are in use in things like Unreal 
Engine and Unity all suffer from the same problem - they can't do 
the compile time tricks we can do in D, and as such you are 
always left with resolving components via a runtime lookup. All 
the compile time safety we can introduce in D really isn't 
possible without doing separate pre-processing.

But a D system? It could look at the data definitions and 
generate code objects for any given component layout at compile 
time.

The easiest way to implement that? Embed them all within a 
containing struct. Multiple alias this in this case would make 
exposing functionality and variables contained within each 
component a trivial matter. Without multiple alias this, you have 
to do exactly what I do with Binderoo C++ binding and parse each 
relevant object to generate wrapper functions for it. Up goes the 
compile time.

(And related - code safety becomes template constraints checking 
exactly how you check if a range is a forward range etc.)

Similarly to this - the behaviors system I talked about in my 
DConf talk this year that provided a decent facsimile for partial 
classes in C# is actually secretly a component system. Just not 
one that I intend on putting in to widespread use. It's 100% 
habit for me at this point in time to write discrete code objects 
and combine them outside of traditional object oriented 
programming methodology.

The implication here also is that component-based programming is 
not a method that the games industry is going to drop any time 
soon. If you're doing console game development, you need to be 
familiar with how to use components.

And with D, we can start making that seamless and performant.