SWIG

Jason Roelofs wrote:
> Hey all
> 
> I've been putting together a wrapper around Ogre 3d (www.ogre3d.org 
> <http://www.ogre3d.org>) for Ruby using SWIG 
> (http://ogrerb.rubyforge.org <http://ogrerb.rubyforge.org>) and have run 
> into a brick wall. Ogre makes heavy use of nested classes and to 
> continue effectively and efficiently I need something that properly 
> reads and wraps these classes without hundreds of lines of manual 
> wrapper code. So I've got a few options:
> 
> 1. Build my own wrapper system, much like Boost::Python and Luabind and 
> abandon SWIG entirely
> 2. Take on the task of adding this much-needed functionality to SWIG.
> 
> Option 1 will take a very long time, will be a ton of work and a lot of 
> reinventing the wheel.
> 
> I've given a lot of thought to Option 2, and some research into what 
> it's going to take to "complete" SWIG, as I see it. For one, I can start 
> with the hack-patch that's been submitted and look into making it proper 
> and production quality, or for two I can build another back-end parser 
> using gcc-xml ( http://www.gccxml.org).
> 
> Side note: I've recently found out about CABLE and CABLESwig 
> (http://public.kitware.com/Cable/HTML/Index.html 
> <http://public.kitware.com/Cable/HTML/Index.html>) and while I will give 
> these a look to see if they'll help my situation, SWIG still itself 
> needs this functionality.
> 
> I know I'm not the first one, but the discussion has been sporadic 
> enough that it's hard to know what people have suggested or if there's 
> any work that's been done with this. So I guess before I really start on 
> this, I'd like to hear what others have done, what you guys think of the 
> best way of implementing this, etc.
> 

Hi Jason

It certainly will "complete" the missing functionality in SWIG and there 
are a number of users who are missing this feature quite badly.

I think adding nested classes to the parser is going to be one big job 
in itself and using the cable gcc-xml parser might make this easier, but 
then this isn't really SWIG and is not an actively maintained project as 
far as I'm aware. The main obstacle for SWiG is fixing the parser. Once 
you've got over the parsing issues, then the first step would probably 
be to wrap all the nested classes as if they were global classes, in 
much the same way that classes within different namespaces are wrapped 
as if they are in one global namespace. That way all the language 
modules will then be able to support nested classes. Users might have to 
put in the odd %rename to avoid name clashes, but that isn't a big deal. 
Otherwise you could mangle the names the way the C nested structs are 
wrapped.

Once you've achieved that, then we can all help out more and the 
different language maintainers can improve the nested class support by 
mapping to something analogous in the target language.

There hasn't been any work on this other than that patch in SF. It is a 
big project to take on and we wish you lots of luck. We'll try and help 
as much as we can on this list. However, most of the parser expertise 
lies with Dave Beazley and requires a good grasp of lex/yacc. Please 
keep us up to date on progress (even if you decide not to add this support).

William

On Nov 20, 2007 4:41 PM, William S Fulton <wsf@...> wrote:

> Jason Roelofs wrote:
> > Hey all
> >
> > I've been putting together a wrapper around Ogre 3d (www.ogre3d.org
> > <http://www.ogre3d.org>) for Ruby using SWIG
> > (http://ogrerb.rubyforge.org <http://ogrerb.rubyforge.org>) and have run
> > into a brick wall. Ogre makes heavy use of nested classes and to
> > continue effectively and efficiently I need something that properly
> > reads and wraps these classes without hundreds of lines of manual
> > wrapper code. So I've got a few options:
> >
> > 1. Build my own wrapper system, much like Boost::Python and Luabind and
> > abandon SWIG entirely
> > 2. Take on the task of adding this much-needed functionality to SWIG.
> >
> > Option 1 will take a very long time, will be a ton of work and a lot of
> > reinventing the wheel.
> >
> > I've given a lot of thought to Option 2, and some research into what
> > it's going to take to "complete" SWIG, as I see it. For one, I can start
> > with the hack-patch that's been submitted and look into making it proper
> > and production quality, or for two I can build another back-end parser
> > using gcc-xml ( http://www.gccxml.org).
> >
> > Side note: I've recently found out about CABLE and CABLESwig
> > (http://public.kitware.com/Cable/HTML/Index.html
> > <http://public.kitware.com/Cable/HTML/Index.html>) and while I will give
> > these a look to see if they'll help my situation, SWIG still itself
> > needs this functionality.
> >
> > I know I'm not the first one, but the discussion has been sporadic
> > enough that it's hard to know what people have suggested or if there's
> > any work that's been done with this. So I guess before I really start on
> > this, I'd like to hear what others have done, what you guys think of the
> > best way of implementing this, etc.
> >
>
> Hi Jason
>
> It certainly will "complete" the missing functionality in SWIG and there
> are a number of users who are missing this feature quite badly.
>
> I think adding nested classes to the parser is going to be one big job
> in itself and using the cable gcc-xml parser might make this easier, but
> then this isn't really SWIG and is not an actively maintained project as
> far as I'm aware. The main obstacle for SWiG is fixing the parser. Once
> you've got over the parsing issues, then the first step would probably
> be to wrap all the nested classes as if they were global classes, in
> much the same way that classes within different namespaces are wrapped
> as if they are in one global namespace. That way all the language
> modules will then be able to support nested classes. Users might have to
> put in the odd %rename to avoid name clashes, but that isn't a big deal.
> Otherwise you could mangle the names the way the C nested structs are
> wrapped.
>
> Once you've achieved that, then we can all help out more and the
> different language maintainers can improve the nested class support by
> mapping to something analogous in the target language.
>
> There hasn't been any work on this other than that patch in SF. It is a
> big project to take on and we wish you lots of luck. We'll try and help
> as much as we can on this list. However, most of the parser expertise
> lies with Dave Beazley and requires a good grasp of lex/yacc. Please
> keep us up to date on progress (even if you decide not to add this
> support).
>
> William
>

For the record, GCC-XML is in active development (see:
http://www.gccxml.org/Bug/my_view_page.php), they just haven't gotten around
to make an official release in some time.

I'll definitely keep you guys up to date with what I do with my project.
Thanks for the support.

Jason

On Nov 20, 2007, at 3:41 PM, William S Fulton wrote:
>
>
> Once you've achieved that, then we can all help out more and the
> different language maintainers can improve the nested class support by
> mapping to something analogous in the target language.
>
> There hasn't been any work on this other than that patch in SF. It  
> is a
> big project to take on and we wish you lots of luck. We'll try and  
> help
> as much as we can on this list. However, most of the parser expertise
> lies with Dave Beazley and requires a good grasp of lex/yacc. Please
> keep us up to date on progress (even if you decide not to add this  
> support).
>
>

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.

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?

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.

Cheers,
Dave

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);

William

On Nov 22, 2007 6:51 PM, William S Fulton <wsf@...> 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);
>
> William


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.

Jason

On Nov 22, 2007 9:25 PM, Jason Roelofs <jameskilton@...> wrote:

> On Nov 22, 2007 6:51 PM, William S Fulton <wsf@...> 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);
> >
> > William
>
>
> 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.
>
> Jason
>
>
>
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.

Jason

Jason Roelofs wrote:
> On Nov 22, 2007 9:25 PM, Jason Roelofs <jameskilton@... 
> <mailto:jameskilton@...>> wrote:
> 
>     On Nov 22, 2007 6:51 PM, William S Fulton <wsf@...
>     <mailto:wsf@...>> 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);
> 
>         William
> 
> 
>     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.
> 
>     Jason
> 
> 
> 
> 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.
> 

I've no idea whether it is possible to integrate gccxml into swig as 
you'd have to get this parser to understand the swig % directives and 
stop it from following #include statements (unless -includeall is 
specified). Have you looked into this? I'd love to see swig using gcc as 
the front end as it can then truly cope with any c++ including the 
changes in the upcoming c++0x standard.

If you get the SWIG Ruby module working with nested classes, the other 
language modules will follow on in time. I still think that this project 
should be taken one step at a time, where the C++ nested classes are 
treated as global classes by each language module in much the same way 
that C nested struct are treated. That way a default approach will work 
without extensive language module changes. Making nested classes more 
integrated into each language module can then come at a later stage. I 
think most people will be grateful for this initial global treatment of 
nested class support.

William

On Dec 27, 2007 5:16 PM, William S Fulton <wsf@...> wrote:

> Jason Roelofs wrote:
> > On Nov 22, 2007 9:25 PM, Jason Roelofs <jameskilton@...
> > <mailto:jameskilton@...>> wrote:
> >
> >     On Nov 22, 2007 6:51 PM, William S Fulton <wsf@...
> >     <mailto:wsf@...>> 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);
> >
> >         William
> >
> >
> >     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.
> >
> >     Jason
> >
> >
> >
> > 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.
> >
>
> I've no idea whether it is possible to integrate gccxml into swig as
> you'd have to get this parser to understand the swig % directives and
> stop it from following #include statements (unless -includeall is
> specified). Have you looked into this? I'd love to see swig using gcc as
> the front end as it can then truly cope with any c++ including the
> changes in the upcoming c++0x standard.
>
> If you get the SWIG Ruby module working with nested classes, the other
> language modules will follow on in time. I still think that this project
> should be taken one step at a time, where the C++ nested classes are
> treated as global classes by each language module in much the same way
> that C nested struct are treated. That way a default approach will work
> without extensive language module changes. Making nested classes more
> integrated into each language module can then come at a later stage. I
> think most people will be grateful for this initial global treatment of
> nested class support.
>
> William
>

Sorry, I meant to say that I don't want to see all of YACC removed, as the
SWIG definition language is well defined and works fine this way, I just
want to see the C++ part of the parser turn into something that's closer to
the actual C++ spec. However, I do understand the concern about GCCXML being
an external requirement that is itself not really a stable library.

Jason