Extending a C++ App

[Bwuce_Wee]

Thanks for all your help
I've been offline for a few days :)

Ive been doing some more investigations, and I thought you guys might
be interested in it.
Firstly - like you indicated - I found the shadow class code that SWIG
generates (Duh I feel stoopid)

As for the DLL thing, apparently, I just need to do this:
Py_Initialize();
SWIG_init();

... Whatever I need to do (eg. PyRun_SimpleString / File) ...

Py_Finalize();

The python code I run in there can then import from whatever I called
my module

Another thing I found was the nebula source code
  (nebula is a 3D game engine by radon labs - who released the source
code)
Nebula gave me lots to think about
(Once I had gotten over my headaches from figuring out the code)
PS: get ready for a long description :)

Nebula opens the possibility of having one of multiple scripting
languages - and easy remote scripting and serialisation.
The way nebula works with python is by having a 'root' class that
handles Cmd objects - which are simply wrappers for a function call
(with ins and outs)
Aside from this, 'root' also handles RTTI and serialisation
Each child class (inheriting root) indicates which command prototypes
it accepts - with ulong ID's for speed,etc. eg.
   AddCmd("v_MyMethod_s", 'MM  ', PointerToFunction);
The 'v_' indidates void and the '_s' indicates string meaning that
MyMethod returns nothing and accepts a string parameter
Unfortunately this *does* mean writing separate static functions for
the commands the class accepts.

The ScriptingServer class - this is the base class - runs/parses
script commands, converts (where necessary) to Cmd objects and hands
the Cmd objects to the appropriate object instances that need to
handle them.
So.. for instance, you could have a PythonScriptingServer and a
TCLScriptingServer - each capable of converting the language into Cmd
objects and handing the Cmd objects to the application.

I would envisage rather having shadow classes created automatically
based on a classes' list of Cmd prototypes. Those shadow classes could
simply be passing Cmd commands to the scripting server to hand over to
the rest of the application.
In these situations, you only really need a handful of functions
extended to python (eg. SendCmdMessage(ObjectID, Arguments) - ObjectID
would differ according to how one identifies an object instance (void*
or long ID or name,etc)

This method potentially allows for remote scripting (which nebula DOES
seem to allow) but Im still deciphering exactly how they did that (eg.
identification of object instances is still not clear to me)

Another nice side effect is serialisation
Nebula uses Cmd commands to serialise and deserialise.
When an object needs to be saved - it simply generates Cmd objects
describing the commands necessary to reconstruct the object, and
passes them to the application to save to file
To deserialise, those Cmd objects simple need to be read in and passed
to a newly created object to reconstitute it

For a while I was brainstorming how to allow my app to optionally not
use Python at all (or any scripting), but still serialise easily (eg.
Pickle). However, I could not find a reasonable way of doing this -
and nebula's method looks like a fair alternative as Cmd commmands
could still be used outside of scripting.

If you read this far - good going :)

Thanks for the help and effort