[Adonthell-devel] Splitting the engine into modules

[Alexandre Courbot]

I've done some extensive tests with swig and yes! It appears that
eventually, we can split our project into different
subdirectories/namespaces/modules! :)

As for now, swig doesn't like namespace declarations. It will generate
lots of bullshits in the wrapper file if it meets one, which won't
compile. So we'd have to enclose namespace declarations info #ifndef
SWIG statements. We'd also need to define some rules about what goes
into a subdirectory.

Every subdirectory would correspond:
-on C++ side, to a namespace.
-on Python side, to a module.

This implies that everything, absolutely everything declared in the
"gfx" subdirectory for example is part of the "gfx" namespace, and that
the Python wrapper file encloses everything into the "gfx" module too.

Let's take a simple example, which has the following architecture:
myproject/
  gfx/
    image.h
    animation.h
    gfx.i
  map/
    landmap.h
    map.i

both image and animation class would be part of the gfx namespace, while
landmap is part of the map namespace. gfx.i and map.i declares
respectively a gfx and map module, and includes all the .h files in the
directory they are in.

This is quite convenient to do so, because when you look closely at
them, you realise that namespaces and modules are just the same thing:
you can access to their members indirectly (gfx.image for example) or
say "using namespace gfx" or "from gfx import *" and have direct access.
So usage from C++ or from Python will just be the same, as it was
already.

I said a few days ago that passing an image (part of the gfx module) as
the argument of a map_object function for example (part of the map
module) wouldn't work. Well, I'm glad to say I've been wrong! Maybe it's
swig that fixed that or me that screwed up, but I just tried it again,
and it does work flawlessly.

Another point if we use namespaces is how strings are handled. Until
now, we used them as "string" but if we make a wiser use of namespaces
we'd have to handle "std::string" as well. 

Making a swig typemap for std::string works perfectly. So the trick
would be to forbid statements like "using namespace std" in the whole
code, and so oblige everybody to declare std::string instead of string,
std::vector instead of vector, etc... This is the normal way to program
anyway - what we did (working directly in the std namespace) is... dirty
:) So unless anyone complains, I'd say we should do this. It'd be highly
recommended to compile with gcc >= 3.0 then, as gcc < 3.0 doesn't
complain if you use 'string' directly for example (even if you haven't
explicitely said you were working in the std namespace).

If we decide to do so, remains to decide:
-what will be our naming scheme,
-what will go where (quite obvious, actually)
-dependancies between the differents subsystems

...and we'll have a much cleaner and functionnal code! :) We could
finally get rid of these awfull "using namespace std" we put a bit
everywhere.

Once everything is set up, I'll start with the gfx code as a real-size
test, to see if everything really works as we want. Then we could
gradually reorganise the code to get something really clean this time.

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