adonthell-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Adonthell-devel] Splitting the engine into modules


From: Kai Sterker
Subject: Re: [Adonthell-devel] Splitting the engine into modules
Date: Thu, 28 Feb 2002 19:03:07 +0100

Am 2002.02.28 18:25:41 +0100 schrieb(en) 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! :)

[...]

> 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.

Right. Now that you say it, it's pretty obvious. Don't know wy we did not
notice that before.
 
 

> 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).

No problem with that.


> If we decide to do so, remains to decide:
> -what will be our naming scheme,

I guess we should try to find short names for the stuff. Like 'gfx' or
'map' and the like.


> -what will go where (quite obvious, actually)

Most things are obvious, indeed. So far I come up with at least the
following modules:

gfx, map, input, py, atk, audio, item, chr, dlg


> -dependancies between the differents subsystems

Well, we can't really avoid dependencies. Practically everything will
depend on python, and everything that contains some sort of gui (like the
dialogue stuff or loading/saving) will depend on input and window system as
well. That's nothing to worry much about though, I think.

Kai



reply via email to

[Prev in Thread] Current Thread [Next in Thread]