Re: [Swig-devel] SWIG's missing feature: Nested classes

[Jason R. <jam...@gm...>]

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