From: Jason R. <jam...@gm...> - 2007-11-19 14:37:59
|
Hey all I've been putting together a wrapper around Ogre 3d (www.ogre3d.org) for Ruby using SWIG (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) 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. Jason |
From: William S F. <ws...@fu...> - 2007-11-20 21:41:38
|
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 |
From: Jason R. <jam...@gm...> - 2007-11-20 22:48:16
|
On Nov 20, 2007 4:41 PM, William S Fulton <ws...@fu...> 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 |
From: David B. <dav...@da...> - 2007-11-21 13:54:11
|
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 |
From: William S F. <ws...@fu...> - 2007-11-22 23:51:57
|
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 |
From: Jason R. <jam...@gm...> - 2007-11-23 02:25:04
|
On Nov 22, 2007 6:51 PM, William S Fulton <ws...@fu...> 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 |
From: Jason R. <jam...@gm...> - 2007-12-27 03:27:39
|
On Nov 22, 2007 9:25 PM, Jason Roelofs <jam...@gm...> wrote: > On Nov 22, 2007 6:51 PM, William S Fulton <ws...@fu...> 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 |
From: William S F. <ws...@fu...> - 2007-12-27 22:16:44
|
Jason Roelofs wrote: > On Nov 22, 2007 9:25 PM, Jason Roelofs <jam...@gm... > <mailto:jam...@gm...>> wrote: > > On Nov 22, 2007 6:51 PM, William S Fulton <ws...@fu... > <mailto:ws...@fu...>> 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 |
From: Jason R. <jam...@gm...> - 2007-12-27 22:21:18
|
On Dec 27, 2007 5:16 PM, William S Fulton <ws...@fu...> wrote: > Jason Roelofs wrote: > > On Nov 22, 2007 9:25 PM, Jason Roelofs <jam...@gm... > > <mailto:jam...@gm...>> wrote: > > > > On Nov 22, 2007 6:51 PM, William S Fulton <ws...@fu... > > <mailto:ws...@fu...>> 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 |