adonthell-devel
[Top][All Lists]
Advanced

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

Re: [Adonthell-devel] SWIG issues


From: Alexandre Courbot
Subject: Re: [Adonthell-devel] SWIG issues
Date: Mon, 24 Jun 2002 15:06:49 +0200

> I've just seen that SWIG 1.3.12/1.3.13 have been released since I last
> looked at their site. I tested 1.3.13 and fortunately, nothing seems
> to be broken. Moreover, these new releases add full support for C++
> namespaces. I didn't investigate how that works yet, but I guess it'll
> be useful for us.

Ah, I'm done with university! Yes, Joel told me about it some days ago.
This looks truly interesting, but I wonder how they supported
namespaces. As I need to get back into the project I thought about doing
a light task first, like reorganizing our code into namespaces and
directories, and ensuring support for GCC 3.1 (currently it doesn't
compile with it). So doing it, I can also take care of the new SWIG.

> Another issue I wanted to raise a while ago is the methods we make
> available to Python. Right now we simply wrap every public method,
> whether it is useful or not. I think it would make sense to exclude a
> number of methods. The put_state/get_state pair comes to mind, init
> and cleanup methods, and probably many others too.

Probably. It depends on what we want to provide. If we only want to use
Python for schedules and such, that's fine. But if we want something
more powerful, like, say, additional rules and such, then maybe the
saving methods would be useful. Of course, it's quite easy to
purge/unpurge some methods, so either way we can easily rollback.

> Should we ever need to access a method we've excluded, it's no big
> deal to change that. However, minimizing the amount of methods
> available from Python makes it easier for 'outsiders' to write
> scripts, simply because the API is lean and focused on the important
> stuff.
> 
> 
> As a side effect, it'll reduce size of wrapper code and shadow
> classes.

How true!

Alex. (yes, I'm back!)
-- 
http://www.gnurou.org




reply via email to

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