Re: [Swig-devel] Nested classes. Was: 2 SWIG patches (C#) and a question

[David B. <da...@da...>]

On Jan 9, 2013, at 5:36 AM, Vladimir Kalinin wrote:

>>> On Jan 8, 2013, at 4:59 PM, William S Fulton wrote:
>>>>> On 08/01/13 14:20, Vladimir Kalinin wrote:
>>>> Now, the question:
>>>> Currently I'm working at the nested classes support for C# module. I
>>>> already fixed parser.y, typepass and lang.cxx and working on
>>>> the csharp module itself. One thing I don't understand - why was it
>>>> disabled at the parser level? I mean why the pain with that weird
>>>> "nestedworkaround" approach, reentering the parser (obviously not
>>>> designed for reentrance)? I fear that I'm missing something essential. Who is the
>>>> right person to discuss this with? (I may commit my current state of
>>>> work to some remote repository to review. Not that there is much to look at,
>>>> but at least the symtables are generated correctly (or so it seems))
>>>> 
>>>> (I didn't touch the templates yet, that is where main parsing problems are
>>>> supposed to be.)
>>>> 
>>>> 
>>> Nested class support will be a big step forward for SWIG, so good to 
>>> hear about this. I don't know why the nested class support in the parser 
>>> is a gross hack (the reentering parser bit), probably ease of 
>>> implementation targeting C in the first instance. I think back in about 
>> 
>>> 2000 when SWIG was going through a lot of development, this problem was 
>> 
>>> put on the TODO later list, but it never got attended to. Dave Beazley 
>>> probably knows more, but he isn't involved much these days.
>>> 
>> 
>> The implementation of nested classes in SWIG has always been
>> complicated due to two historical factors.  First, many of the
>> target languages supported by SWIG don't actually support nested
>> classes themselves (or if they do, the support is weak/flaky). 
>> Second, the implementation of SWIG's various language modules didn't
>> allow class code to be emitted in a manner that was reentrant.  That
>> is, if you were in the middle of emitting code for a class, you
>> couldn't just suspend it temporarily and enter a nested code generation context.
>> 
>> The "solution" to both of these problems was to have the parser
>> forcefully unnest the class definitions and play some hacks with
>> parsing and  typenames.    Specifically, if a nested class was
>> found, the parser would simply capture the whole class definition
>> body and set it aside.  After the enclosing class was fully
>> processed, the body of the nested class would then be processed as
>> if it were a separate unnested class definition.    A typedef like
>> "typedef Outer::Inner Outer_Inner" would be made somewhere in the
>> emitted code and the class wrapped as if it were actually called "Outer_Inner".   Yes, a hack.
>> 
>> A major reason why nested class support has never been implemented
>> to this day is due to the fact that making it work would probably
>> require a major refactoring of all of the target language modules to
>> allow reentrant class wrapping.   Given the large number of modules,
>> it's a major task.  I just don't think anyone has been motivated enough to tackle it.
>> 
>> I'm not sure if this helps, but it's a bit of history about why
>> there are some really gross hacks in there ;-). 
>> 
> 
> I quite understand why the nested classes were not implemented, I just
> wondered why it was easier to implement the workaround on the parser
> level, not as a parse tree transformation.
> I think that will have to be done now anyway, because as you correctly
> point out, there are languages w/o nested classes support at all.
> I think it should be possible to implement the same %feature
> nestedworkaround in the typepass, or maybe just before it. At least
> some kind of feature should be introduced, because it is impractical
> to expect all the language modules be refactored at once. I personally
> know well enough only C# and perhaps Java.
> 

Doing it at the parser level is probably a historical artifact.  SWIG started out as a 1-pass parser that simply emitted code without ever building an intermediate parse tree.    Obviously that's different now, but the original implementation of the parser still carries that baggage.   There was probably no motivation to fix it given that nested classes weren't supported in the target languages anyways.

Cheers,
Dave