David Beazley wrote:Yes, the target language modules would need some rewriting, but it would
> 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
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.
In my mind, offer a feature to wrap nested classes as global proxy
> 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?
classes or as true nested classes.
This would be great. There are some higher priority parser bugs which
> 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.
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:
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