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

[Kai Sterker]

On Tue, 18 Mar 2003 20:15:49 +0100 Alexandre Courbot wrote:

> 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

Great. As I am back at uni again, I won't have as much time as during
the last few weeks. But if you're making such progress, that's very
motivating :).


Oh, something that crossed my mind: one thing where we depend on SDL is
endian independence. But AFAIK, that are just a few macros to take care
of that. Might be a good idea to move that into our own code, as it
would remove one external dependency.
Not that this needs to be done immediately. But we might want to keep it
in mind for later.


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

Yeah, that's cool. I've been reading a lot about unit testing lately,
and they also use this technique quite a lot. 


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

Indeed.

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

As I said earlier, the swig library is nothing more than a single C
file. Actually, it is that code that gets copied to the top of each
wrapper. So I don't think it hurts to distribute that file together with
our source (as we do with SDL mixer). That would mean no additional
dependencies for the user, and would solve our problems in quite a nice
way, I think.

Btw, to create that file, cd into SWIG-1.3.1x/Runtime/ and run 
'make python'.

Kai