On Nov 22, 2007 9:25 PM, Jason Roelofs <jameskilton@gmail.com> wrote:
On Nov 22, 2007 6:51 PM, William S Fulton <wsf@fultondesigns.co.uk> wrote:
David Beazley wrote:
> For what it's worth,  making the SWIG parser properly handle nested
> classes would actually be a fairly easy thing to do (in fact, doing so
> would probably simplify the parser).    The SWIG type system should also
> be capable of supporting nested classes as there is not much difference
> between nested classes and namespaces.   In my mind, the big obstacle to
> supporting nested classes is knowing what to do with them in all of the
> SWIG language modules.   For one, not all languages support nested
> classes---so, you would need to find some way to flatten them.
> However, a bigger problem is the execution model of the language
> modules.  For instance, to create a class wrapper, there are a whole
> sequence of steps that execute (opening the class, populating it with
> method wrappers, closing the class, etc.).  The last time I checked,
> none of this code was safely reentrant---meaning that you couldn't start
> wrapping a nested class if you were already wrapping another class.
> Fixing this would require rewriting significant portions of every single
> SWIG target module.   That's the real reason why this hasn't been
> addressed.
Yes, the target language modules would need some rewriting, but it would
be applying the same recipe to all of them, so once one is worked out
the others should follow fairly easily. Personally, I don't see that
making the code reentrant as particularly challenging, but I'm
completely stumped when it comes to the parser. However, coming up with
a good mapping of C++ nested classes to whatever is the equivalent in
the target language is going to have a number of subtle challenges as
the concepts do not always map one to one.

Consequently, I think that as a first step, nested classes should be
treated the same way as the C nested structs are at the moment in that a
global proxy class should be generated. Personally, I think most users
would be very happy to have just this feature as then nested classes are
supported, even if in a non-ideal way (akin to the way that SWIG
flattens namespaces). I think this wrapping of nested classes as a
global class is important as I suspect some target languages may not
even have a concept of a nested class.

The second step would then be to get one target language module
reentrant or hacking in support for David Piepgrass' idea of putting the
nested class as the last node in the class. Then finally code up true
nested class mapping in the target languages.

> I think if people are really serious about nested classes, we should
> come up with some kind of concrete proposal about how we intend to
> handle them in the target language modules.  For example, what is the
> execution model?   Do we provide some kind of backwards compatibility
> with target modules than can't handle them?  Do we provide options for
> different types of nested class wrapping?
In my mind, offer a feature to wrap nested classes as global proxy
classes or as true nested classes.

> I know I've been taking a break from SWIG development for the last
> couple of years, but I have been thinking about getting back into it in
> 2008.   Nested class support is certainly something that I could start
> to take a look at if there is a lot of interest in it.

This would be great. There are some higher priority parser bugs which
hopefully wouldn't take you too long to be fix first. I think the fact
that SWIG can't parse the following basic variable declaration
initialisation atm is pretty poor:

int i(0);

I had a go at hacking the parser over the last couple of days, but
failed miserably as this kind of declaration is too close to a method
declaration such as

int i(int);


All this is definitely good information to know and I'll definitely work on some sort of proposal to any changes I'd like to see made in SWIG, mainly because this is all pretty new to me. I'll be spending a good bit of time just looking through the code, testing things out and just getting an understanding of how the whole system works.


So yeah, I've spent a good bit of time looking through the code, through the parser, and I see in general what needs to be changed and yeah it's going to be a lot of work, work that I'm not sure if I'm up to it, mostly because the code feels quite brittle, when keeping in mind all of the language modules. I still feel that getting away from a YACC parser is the best way to make SWIG a better library overall. So for now I'm looking into building a Ruby-specific wrapper generator, though I may look more into integrating GCCXML to SWIG, I'm currently split between the two.