On Dec 27, 2007 5:16 PM, William S Fulton <wsf@fultondesigns.co.uk> wrote:
Jason Roelofs wrote:
> On Nov 22, 2007 9:25 PM, Jason Roelofs <jameskilton@gmail.com
> <mailto: jameskilton@gmail.com>> wrote:
>     On Nov 22, 2007 6:51 PM, William S Fulton <wsf@fultondesigns.co.uk
>     <mailto: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);
>         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.


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.