Re: [Swig-devel] [Swig-user] SWIG plugins - was: Working with object identities in target languages

[John L. <jl...@ma...>]

On 04/11/2008 06:15 AM, Nitro wrote:
> 
> I've got a question. Is it possible to extend swig like the following:
> 
> 1. SWIG parses the source, creating the parse tree
> 2. I'll add a plugin-facility to SWIG. The first plugin I'd write would be  
> a python wrapper around swig's parse tree and code output methods. The  
> user can register to handle certain types of nodes or to handle all nodes  
> or loop over the nodes manually. SWIG calls this plugin with the parse  
> tree as argument.
> 3. The user code will now be invoked and can handle things like generating  
> a proxyclass definition itself. So things like adding your custom base  
> class can be customized this way.
> 4. The plugin-facility basically replaces the current hardcoded language  
> modules like Python.cxx. So to integrate with them the first plugin would  
> contain a rewrite of the c++ version.
> 5. The plugin could probably be extended to the "creating parse tree"  
> phase. For example to generate %renames() on the fly. This would make the  
> two step xml parsing approach unneccessary.
> 
> My main idea behind this is that swig's going too crazy with all the  
> different %features/%typemaps etc.. I don't think there's anybody who  
> knows all of them. Yet SWIG doesn't allow for certain behaviour. Once we  
> discussed rewriting SWIG entirely. Maybe the plugin approach can make this  
> unneccessary (and is probably faster since the parsing backend is still  
> c++).
> 
> What do you guys think?
> 

I'm moving this thread to swig-devel, and trimming the CC list a little,
since it is orthogonal to the original thread.

Maybe it is just a poor choice of using the word plugin, but I would be
hesitant to try something like this.

I think having the ability to transform the parse tree is a good idea, but
this is a place where the complexity must be carefully managed.

I would think if you have a bunch of plugins, they will have a very large
amount of interdependencies.  If we let plugins be combined arbitrarily,
even with user written ones, I would think we would get into a very nasty
dependency and just a general complexity problem, where we need to
maintain backwards compatibility and publish and stick to some API.

I would be more in favor of allowing transformations of the parse tree,
but not making these things plugins.  Instead, just integrate them
directly into the SWIG code, so we can manage the order in which they are
run, we can write the transformations to assume previous transforms, and
don't need to maintain compatibility between versions, so on.  I am not
really explaining this all that well, but I hope you get the idea.

I always thought it would also be nice if the typemaps could be generated
by python instead of having to use macros.  The UTL isn't all that bad of
an idea, where we write code to produce the %typemap stuff, but the
problem is it is very convoluted having to use macros, instead of python
or something.  The thing here is that these python scripts do not need any
 API from SWIG, because they just output text.  Thus these would have a
smaller complexity and interdependency than the transformations above.

Just some ideas for comment...

John