>>>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.
Oh, that explains it, thanks.