[Alephmodular-devel] Build-selectable binding time

[Woody Z. I. <woo...@sb...>]

Hi,

I was thinking, for a lot of this stuff it may make sense to use like 
classes, so that we can easily group interfaces and ensure some degree 
of consistency in their use, and also so that some modules can inherit 
some routines but override others.

So that would tend to point toward using effectively an 'interface', 
i.e. a base class with lots of pure virtual functions, that subclasses 
override.

But in many cases there will always be only one actual concrete subclass 
used in any given build of the program.  (For example, the Carbon build 
is probably always going to use the CarbonWidgetManager or whatever, and 
a build with SDL widgets will always use the SDLWidgetManager.)  So it 
seems to make sense to allow that choice of subclass to be made at 
compile-time; thus the compiler and linker can take advantage of this 
"advance knowledge" to produce better code.

But we don't want to _require_ that it be specified at build-time, in 
case e.g. some platform can use any of several different implementations 
of a given interface, and the choice may be made at runtime (either 
automatically, or by some kind of explicit configuration in the UI or in 
a file of some sort).

I haven't thought this all the way through, but it seems to me that 
using preprocessor symbols for the type names (and probably for the 
'virtual' keyword) could let us choose.  That is, maybe you have

class DatagramSystem { lots of pure virtual methods };
class SDLNetUDPDatagramSystem : public DatagramSystem { yadda };
class OpenTransportUDPDatagramSystem : public DatagramSystem { yadda };

Now typically, code that's going to use this would like, ask for the 
current DatagramSystem with NetworkCoordinator->GetDatagramSystem(), 
which would return a DatagramSystem* that really points at, say, an 
SDLNetUDPDatagramSystem.  Everything works fine.  But maybe this 
DatagramSystem is the only one that's ever going to make sense in this 
build (at least until there are more DatagramSystems written).  So we'd 
rather have it appear that all of SDLNetUDPDatagramSystem's methods are 
nonvirtual, and that GetDatagramSystem() returns an 
SDLNetUDPDatagramSystem*, so that the compiler and linker have better 
information to work with.

So maybe there's some kind of post-configuration file (that's always the 
same) that does

#ifndef DATAGRAMSYSTEM
#define DATAGRAMSYSTEM DatagramSystem
#define DATAGRAMSYSTEM_VIRTUAL virtual
#else
#define DATAGRAMSYSTEM_VIRTUAL
#endif

so then a configuration file (or build flag etc.), which can be 
different on different platforms or in different builds, can optionally 
do

#define DATAGRAMSYSTEM SDLNetUDPDatagramSystem

to establish the binding early, or leave DATAGRAMSYSTEM undefined to get 
the most-generic, most-dynamic behavior.

class DatagramSystem { would have DATAGRAMSYSTEM_VIRTUAL bool 
SendDatagram(...); etc. }, so the preprocessor could determine whether 
the methods are really virtual or not.

users of the DatagramSystem would use DATAGRAMSYSTEM* instead of 
DatagramSystem*, so that the preprocessor could rewrite them to the 
specific subclass if desired.

Hmm, although, users of DATAGRAMSYSTEM would also have to somehow 
#include the proper header for the specific subclass if a subclass is 
used at compile-time.  Hmm.  Well could you just do

// This part would be in a standard header file somewhere
// I think this two-level separation is needed to make sure that 'a' 
gets expanded to the real classname before being stringified.
#define MAKE_HEADER_FILENAME(a) REALLY_MAKE_HEADER_FILENAME(a)
#define REALLY_MAKE_HEADER_FILENAME(a) #a ".h"

// This part would be found in files that use DATAGRAMSYSTEM
#include MAKE_HEADER_FILENAME(DATAGRAMSYSTEM)

This is just a random thought I had, it seemed reasonably 
straightforward and made sense to me, but maybe any gains to be gotten 
from it are not worth the extra fuss.  Virtual method calls aren't 
_that_ expensive I suppose, at least not when only made once (or a 
hundred times) a tick or so.  (Now, tens of thousands of times per 
tick... maybe it'd be worth it ;) )

Whatdya think?  Kooky?  Or, surely someone else somewhere has thought of 
this before, and has come up with The Best Way of doing it...

Woody