[Adonthell-devel] New structure status, thoughts, and problems

[Alexandre Courbot]

I'm just too lazy to make reports, but the new structure is coming along
very well! Actually, it could already be finished, but as I want to
improve some basic stuff, it takes a few more changes.

For now, I've integrated:
-base
-gfx (quite changed, with a (hopefully) better and easier to use
structure)
-input

Both gfx and input use backends - that is, you specify at module
initialisation time which backend you want to use (for now, only "sdl"
is a valid option of course).

This is where the problems arise. Kai mentionned a while ago some
problems we could have by separating stuff into several modules. Here is
what is safe and what is not:
-Types are identified by their textual name. This makes it possible to
pass and receive arguments or return values of classes defined in
another module (i.e. in the "map" module is would be ok to pass
arguments of type gfx::surface).
-However, modules have no information at all about the relationships
between the classes of other modules. Let me explain why this can suck
with a little example of what I wanted to make:

We are going to use callbacks heavily. Both in the game itself
(schedules) and for the user interaction (GUI, inputs). And we want to
support both C++ and Python callbacks. Which implied that all the
modules that support callbacks depends on Python, as we had to define
two callback types (one for C++, one for Python).

I wanted to use a more convenient (yet not perfect, as you'll see)
structure: the base module would define an abstract callback interface
with a virtual run() method. All the modules that need callbacks would
use this abstract class, and therefore would only depend on base. Then,
in the python module for instance, we could derive base::callback to
make our python::callback class. Thanks to the virtual mechanism, we can
define our own run() method, and the modules that need callbacks can
still use Python callbacks, without requiring being linked with Python
or including Python files. Fine, eh?

Unfortunately, there are some drawbacks:
- I have not thought a lot about arguments and return values handling -
thoughts are welcome on this subject.
- More SWIG related, the input module for instance has no idea that
python::callback is a son of base::callback. Which of course makes it
fail when we want to connect a callback in a Python script. Bad!

There are some workarounds, yet I like none of them:
- Every callback-using module could include all the callback-related
headers files in its SWIG .i file, but... it sucks severely and would be
a big mess.
- We could use the SWIG library, which is supposed to take care of such
problems. But it would require the user to have it. Sucks a lot.

Normally, we are supposed to avoid such inheritance cases between
modules. But it is still quite helpful in cases like this one. Ideas or
suggestions are welcome!

Alex.
-- 
http://www.gnurou.org