From: Vladimir K. <vka...@op...> - 2013-01-31 01:21:28
|
Hi, As it was discussed earlier, not all the target languages support the notion of nested classes. Therefore, there should be introduced some feature, like %feature ("directors"), that will affect nested classes handling. I propose a feature "nested_classes" with 3 modes, emulating old and enabling new nested classes support. Suppose we have a following declaration: struct Outer { struct Nested { int val; } data; }; Then %feature ("nested_classes", "ignore") will skip nested classes, like it was done previously by default and produce a proxy public class Outer {} %feature ("nested_classes", "flatten") - move nested classes to the namespace containing the outer class. Result will look like public class Nested { public int val; } public class Outer { public Nested data;} %feature ("nested_classes", "default") - handle nested classes normally, will result in public class Outer { public class Nested { int val; } public Nested data; } Perhaps there also may be something like %feature ("nested_classes", "rename") which works like "flatten" but prepends outer class name to the generated proxy class name: public class Outer_Nested { public int val; } public class Outer { public Outer_Nested data;} This feature may be inserted in a language-specific .swg file to change the default behaviour, when the necessary changes are made in the language module. Any suggestions? Vladimir. |
From: William S F. <ws...@fu...> - 2013-01-31 20:37:23
|
On 31/01/13 01:21, Vladimir Kalinin wrote: > Hi, > > As it was discussed earlier, not all the target languages support the notion > of nested classes. Therefore, there should be introduced some feature, > like %feature ("directors"), that will affect nested classes handling. > > I propose a feature "nested_classes" with 3 modes, emulating old and enabling > new nested classes support. > Suppose we have a following declaration: > > struct Outer { > struct Nested { > int val; > } data; > }; > > Then %feature ("nested_classes", "ignore") will skip nested classes, like it > was done previously by default and produce a proxy > > public class Outer {} > > > %feature ("nested_classes", "flatten") - move nested classes to the > namespace containing the outer class. Result will look like > > public class Nested { public int val; } > public class Outer { public Nested data;} > > > %feature ("nested_classes", "default") - handle nested classes > normally, will result in > > public class Outer { > public class Nested { > int val; > } > public Nested data; > } > > > Perhaps there also may be something like %feature ("nested_classes", > "rename") which works like "flatten" but prepends outer class name to > the generated proxy class name: > > public class Outer_Nested { public int val; } > public class Outer { public Outer_Nested data;} > > > This feature may be inserted in a language-specific .swg file to > change the default behaviour, when the necessary changes are made in > the language module. > > Any suggestions? > I think this is a good set of proposals, but with a couple of tweaks. Having two ways to ignore a class %ignore and %feature("nested", "ignore") is confusing, especially when both are defined (bearing in mind that %ignore is just a form of %rename). So let's keep %ignore as the way to ignore the nested class. I think that the nested classes must be properly added into the symbol table for this to work, but I'd expect that to happen with your new work. A new predicate could be introduced for nested classes (see %rename predicates in swig.swg). I suggest %$isnested, so then all nested structs could be ignored like this: %rename("$ignore", %$isnested); plus more powerful targeted %rename'ing. That then leaves two different modes for the nested/nested_class feature. The feature could then be a simple feature flag, where the default is as you describe and if the feature is turned on it would turn on the flattening mode. %ignore would override both. A short concise name for the feature is needed, maybe %feature("flatnested"), also as a macro called %flatnested. BTW, the convention is not to use underscores in feature names. %rename should also allow one to change the name from the default flatnested name. I just want to add that this work is rather exciting and to say many thanks. When complete, we'll probably ramp up the version number to 3.0 for the release. William |
From: Vladimir K. <vka...@op...> - 2013-01-31 22:45:20
|
>> Hi, >> >> As it was discussed earlier, not all the target languages support the notion >> of nested classes. Therefore, there should be introduced some feature, >> like %feature ("directors"), that will affect nested classes handling. >> >> I propose a feature "nested_classes" with 3 modes, emulating old and enabling >> new nested classes support. >> Suppose we have a following declaration: >> >> struct Outer { >> struct Nested { >> int val; >> } data; >> }; >> >> Then %feature ("nested_classes", "ignore") will skip nested classes, like it >> was done previously by default and produce a proxy >> >> public class Outer {} >> >> >> %feature ("nested_classes", "flatten") - move nested classes to the >> namespace containing the outer class. Result will look like >> >> public class Nested { public int val; } >> public class Outer { public Nested data;} >> >> >> %feature ("nested_classes", "default") - handle nested classes >> normally, will result in >> >> public class Outer { >> public class Nested { >> int val; >> } >> public Nested data; >> } >> >> >> Perhaps there also may be something like %feature ("nested_classes", >> "rename") which works like "flatten" but prepends outer class name to >> the generated proxy class name: >> >> public class Outer_Nested { public int val; } >> public class Outer { public Outer_Nested data;} >> >> >> This feature may be inserted in a language-specific .swg file to >> change the default behaviour, when the necessary changes are made in >> the language module. >> >> Any suggestions? >> > I think this is a good set of proposals, but with a couple of tweaks. > > Having two ways to ignore a class %ignore and %feature("nested", > "ignore") is confusing, especially when both are defined (bearing in > mind that %ignore is just a form of %rename). So let's keep %ignore as > the way to ignore the nested class. I think that the nested classes must > be properly added into the symbol table for this to work, but I'd expect > that to happen with your new work. A new predicate could be introduced > for nested classes (see %rename predicates in swig.swg). I suggest > %$isnested, so then all nested structs could be ignored like this: > > %rename("$ignore", %$isnested); > > plus more powerful targeted %rename'ing. > > That then leaves two different modes for the nested/nested_class > feature. The feature could then be a simple feature flag, where the > default is as you describe and if the feature is turned on it would turn > on the flattening mode. %ignore would override both. A short concise > name for the feature is needed, maybe %feature("flatnested"), also as a > macro called %flatnested. BTW, the convention is not to use underscores > in feature names. %rename should also allow one to change the name from > the default flatnested name. > Ok, thanks for the comments. To summarize: %$isnested predicate should be be defined, perhaps like this (I'm not en expert on matching syntax, any suggestions are welcome): %define %$and "and" %enddef %define %$isnested "match$nodeType"="class" %$and "match$parentNode$nodeType"="class" %enddef %feature("flatnested") - tuns on "unnesting" of classes in the parse tree. But, would it not cause a problem for all the language modules if default behaviour would be to handle nested classes as nested? (So that to achieve the current default, all the language .swg files should include %ignore statement)) Vladimir |
From: William S F. <ws...@fu...> - 2013-02-01 07:49:19
|
On 31/01/13 22:45, Vladimir Kalinin wrote: >>> Hi, >>> >>> As it was discussed earlier, not all the target languages support the notion >>> of nested classes. Therefore, there should be introduced some feature, >>> like %feature ("directors"), that will affect nested classes handling. >>> >>> I propose a feature "nested_classes" with 3 modes, emulating old and enabling >>> new nested classes support. >>> Suppose we have a following declaration: >>> >>> struct Outer { >>> struct Nested { >>> int val; >>> } data; >>> }; >>> >>> Then %feature ("nested_classes", "ignore") will skip nested classes, like it >>> was done previously by default and produce a proxy >>> >>> public class Outer {} >>> >>> >>> %feature ("nested_classes", "flatten") - move nested classes to the >>> namespace containing the outer class. Result will look like >>> >>> public class Nested { public int val; } >>> public class Outer { public Nested data;} >>> >>> >>> %feature ("nested_classes", "default") - handle nested classes >>> normally, will result in >>> >>> public class Outer { >>> public class Nested { >>> int val; >>> } >>> public Nested data; >>> } >>> >>> >>> Perhaps there also may be something like %feature ("nested_classes", >>> "rename") which works like "flatten" but prepends outer class name to >>> the generated proxy class name: >>> >>> public class Outer_Nested { public int val; } >>> public class Outer { public Outer_Nested data;} >>> >>> >>> This feature may be inserted in a language-specific .swg file to >>> change the default behaviour, when the necessary changes are made in >>> the language module. >>> >>> Any suggestions? >>> >> I think this is a good set of proposals, but with a couple of tweaks. >> >> Having two ways to ignore a class %ignore and %feature("nested", >> "ignore") is confusing, especially when both are defined (bearing in >> mind that %ignore is just a form of %rename). So let's keep %ignore as >> the way to ignore the nested class. I think that the nested classes must >> be properly added into the symbol table for this to work, but I'd expect >> that to happen with your new work. A new predicate could be introduced >> for nested classes (see %rename predicates in swig.swg). I suggest >> %$isnested, so then all nested structs could be ignored like this: >> >> %rename("$ignore", %$isnested); >> >> plus more powerful targeted %rename'ing. >> >> That then leaves two different modes for the nested/nested_class >> feature. The feature could then be a simple feature flag, where the >> default is as you describe and if the feature is turned on it would turn >> on the flattening mode. %ignore would override both. A short concise >> name for the feature is needed, maybe %feature("flatnested"), also as a >> macro called %flatnested. BTW, the convention is not to use underscores >> in feature names. %rename should also allow one to change the name from >> the default flatnested name. >> > > Ok, thanks for the comments. To summarize: > > %$isnested predicate should be be defined, perhaps like this > (I'm not en expert on matching syntax, any suggestions are welcome): > > %define %$and "and" %enddef > %define %$isnested "match$nodeType"="class" %$and "match$parentNode$nodeType"="class" %enddef > I'm not too familiar with these but it looks like you don't need the '%$and' as I think the logical and is used when specifying more than one. I tried experimenting quickly but couldn't get match$parentNode to work even in %$innamespace. Something to sort out later. I havn't looked to see how you mark classes as nested in each node, but if you have added a 'nested' flag in the class node, then: %define %$isnested "match$nested"="1" %enddef > > %feature("flatnested") - tuns on "unnesting" of classes in the parse > tree. > > But, would it not cause a problem for all the language modules if > default behaviour would be to handle nested classes as nested? > (So that to achieve the current default, all the language .swg files > should include %ignore statement)) > The nested implementation would need to be done by each language module. The Language class could decide whether to suppress the nested class code generation for a target language depending on whether or not the target language has registered if it supports nested classes. If a language module has not registered then a "feature:ignore" would be added and a warning message emitted. You could implement it like Language::extraDirectorProtectedCPPMethodsRequired() Regarding 'flatnested'... how will this be implemented? Will you do the current hack of pushing the class back into the parser in the global namespace? What about the symbol tables, how will they appear? William |
From: William S F. <ws...@fu...> - 2013-02-01 07:48:30
|
On 31/01/13 22:45, Vladimir Kalinin wrote: >>> Hi, >>> >>> As it was discussed earlier, not all the target languages support the notion >>> of nested classes. Therefore, there should be introduced some feature, >>> like %feature ("directors"), that will affect nested classes handling. >>> >>> I propose a feature "nested_classes" with 3 modes, emulating old and enabling >>> new nested classes support. >>> Suppose we have a following declaration: >>> >>> struct Outer { >>> struct Nested { >>> int val; >>> } data; >>> }; >>> >>> Then %feature ("nested_classes", "ignore") will skip nested classes, like it >>> was done previously by default and produce a proxy >>> >>> public class Outer {} >>> >>> >>> %feature ("nested_classes", "flatten") - move nested classes to the >>> namespace containing the outer class. Result will look like >>> >>> public class Nested { public int val; } >>> public class Outer { public Nested data;} >>> >>> >>> %feature ("nested_classes", "default") - handle nested classes >>> normally, will result in >>> >>> public class Outer { >>> public class Nested { >>> int val; >>> } >>> public Nested data; >>> } >>> >>> >>> Perhaps there also may be something like %feature ("nested_classes", >>> "rename") which works like "flatten" but prepends outer class name to >>> the generated proxy class name: >>> >>> public class Outer_Nested { public int val; } >>> public class Outer { public Outer_Nested data;} >>> >>> >>> This feature may be inserted in a language-specific .swg file to >>> change the default behaviour, when the necessary changes are made in >>> the language module. >>> >>> Any suggestions? >>> >> I think this is a good set of proposals, but with a couple of tweaks. >> >> Having two ways to ignore a class %ignore and %feature("nested", >> "ignore") is confusing, especially when both are defined (bearing in >> mind that %ignore is just a form of %rename). So let's keep %ignore as >> the way to ignore the nested class. I think that the nested classes must >> be properly added into the symbol table for this to work, but I'd expect >> that to happen with your new work. A new predicate could be introduced >> for nested classes (see %rename predicates in swig.swg). I suggest >> %$isnested, so then all nested structs could be ignored like this: >> >> %rename("$ignore", %$isnested); >> >> plus more powerful targeted %rename'ing. >> >> That then leaves two different modes for the nested/nested_class >> feature. The feature could then be a simple feature flag, where the >> default is as you describe and if the feature is turned on it would turn >> on the flattening mode. %ignore would override both. A short concise >> name for the feature is needed, maybe %feature("flatnested"), also as a >> macro called %flatnested. BTW, the convention is not to use underscores >> in feature names. %rename should also allow one to change the name from >> the default flatnested name. >> > > Ok, thanks for the comments. To summarize: > > %$isnested predicate should be be defined, perhaps like this > (I'm not en expert on matching syntax, any suggestions are welcome): > > %define %$and "and" %enddef > %define %$isnested "match$nodeType"="class" %$and "match$parentNode$nodeType"="class" %enddef > I'm not too familiar with these but it looks like you don't need the '%$and' as I think the logical and is used when specifying more than one. I tried experimenting quickly but couldn't get match$parentNode to work even in %$innamespace. Something to sort out later. I havn't looked to see how you mark classes as nested in each node, but if you have added a 'nested' flag in the class node, then: %define %$isnested "match$nested"="1" %enddef > > %feature("flatnested") - tuns on "unnesting" of classes in the parse > tree. > > But, would it not cause a problem for all the language modules if > default behaviour would be to handle nested classes as nested? > (So that to achieve the current default, all the language .swg files > should include %ignore statement)) > The nested implementation would need to be done by each language module. The Language class could decide whether to suppress the nested class code generation for a target language depending on whether or not the target language has registered if it supports nested classes. If a language module has not registered then a "feature:ignore" would be added and a warning message emitted. You could implement it like Language::extraDirectorProtectedCPPMethodsRequired() Regarding 'flatnested'... how will this be implemented? Will you do the current hack of pushing the class back into the parser in the global namespace? What about the symbol tables, how will they appear? William |
From: Vladimir K. <vka...@op...> - 2013-02-01 13:40:57
|
> > Regarding 'flatnested'... how will this be implemented? Will you do the > current hack of pushing the class back into the parser in the global > namespace? What about the symbol tables, how will they appear? I definitely won't use parser reentrance even if I could. It would require total parser refactoring to make it reliably reentrant. I intend to do the flattening entirely as a parse tree transformation, right after the parsing (before typepass). C symbol table will remain intact, as for the normal symbol tables, I'm not sure yet, maybe they will require modification too. Actually, there is nothing that could be done by the parser, that cannot be done on the parse tree level. Vladimir. |
From: Vladimir K. <vka...@op...> - 2013-02-09 18:43:49
|
>>>> Hi, >>>> >>>> As it was discussed earlier, not all the target languages support the notion >>>> of nested classes. Therefore, there should be introduced some feature, >>>> like %feature ("directors"), that will affect nested classes handling. >>>> >>>> I propose a feature "nested_classes" with 3 modes, emulating old and enabling >>>> new nested classes support. >>>> Suppose we have a following declaration: >>>> >>>> struct Outer { >>>> struct Nested { >>>> int val; >>>> } data; >>>> }; >>>> >>>> Then %feature ("nested_classes", "ignore") will skip nested classes, like it >>>> was done previously by default and produce a proxy >>>> >>>> public class Outer {} >>>> >>>> >>>> %feature ("nested_classes", "flatten") - move nested classes to the >>>> namespace containing the outer class. Result will look like >>>> >>>> public class Nested { public int val; } >>>> public class Outer { public Nested data;} >>>> >>>> >>>> %feature ("nested_classes", "default") - handle nested classes >>>> normally, will result in >>>> >>>> public class Outer { >>>> public class Nested { >>>> int val; >>>> } >>>> public Nested data; >>>> } >>>> >>>> >>>> Perhaps there also may be something like %feature ("nested_classes", >>>> "rename") which works like "flatten" but prepends outer class name to >>>> the generated proxy class name: >>>> >>>> public class Outer_Nested { public int val; } >>>> public class Outer { public Outer_Nested data;} >>>> >>>> >>>> This feature may be inserted in a language-specific .swg file to >>>> change the default behaviour, when the necessary changes are made in >>>> the language module. >>>> >>>> Any suggestions? >>>> >>> I think this is a good set of proposals, but with a couple of tweaks. >>> >>> Having two ways to ignore a class %ignore and %feature("nested", >>> "ignore") is confusing, especially when both are defined (bearing in >>> mind that %ignore is just a form of %rename). So let's keep %ignore as >>> the way to ignore the nested class. I think that the nested classes must >>> be properly added into the symbol table for this to work, but I'd expect >>> that to happen with your new work. A new predicate could be introduced >>> for nested classes (see %rename predicates in swig.swg). I suggest >>> %$isnested, so then all nested structs could be ignored like this: >>> >>> %rename("$ignore", %$isnested); >>> >>> plus more powerful targeted %rename'ing. >>> >>> That then leaves two different modes for the nested/nested_class >>> feature. The feature could then be a simple feature flag, where the >>> default is as you describe and if the feature is turned on it would turn >>> on the flattening mode. %ignore would override both. A short concise >>> name for the feature is needed, maybe %feature("flatnested"), also as a >>> macro called %flatnested. BTW, the convention is not to use underscores >>> in feature names. %rename should also allow one to change the name from >>> the default flatnested name. >>> >> >> Ok, thanks for the comments. To summarize: >> >> %$isnested predicate should be be defined, perhaps like this >> (I'm not en expert on matching syntax, any suggestions are welcome): >> >> %define %$and "and" %enddef >> %define %$isnested "match$nodeType"="class" %$and "match$parentNode$nodeType"="class" %enddef >> > I'm not too familiar with these but it looks like you don't need the > '%$and' as I think the logical and is used when specifying more than > one. I tried experimenting quickly but couldn't get match$parentNode to > work even in %$innamespace. Something to sort out later. I havn't looked > to see how you mark classes as nested in each node, but if you have > added a 'nested' flag in the class node, then: > > %define %$isnested "match$nested"="1" %enddef > I was unable to make the macro work, but the direct approach works ok: %rename("$ignore", match$nested="1") ""; >> >> %feature("flatnested") - tuns on "unnesting" of classes in the parse >> tree. >> >> But, would it not cause a problem for all the language modules if >> default behaviour would be to handle nested classes as nested? >> (So that to achieve the current default, all the language .swg files >> should include %ignore statement)) >> > The nested implementation would need to be done by each language module. > The Language class could decide whether to suppress the nested class > code generation for a target language depending on whether or not the > target language has registered if it supports nested classes. If a > language module has not registered then a "feature:ignore" would be > added and a warning message emitted. You could implement it like > Language::extraDirectorProtectedCPPMethodsRequired() > I called the new method "Language::nestedClassesSupported()" Have you any suggestion about where to put nested classes postprocessing implementation? I currently placed it at the end of the typepass.cxx, because it is somewhat related to the type system. There will be ~400 lines of code (naming of unnamed structures for C and flattening transformation for C++ (the first is done, and the second I hope to finish tomorrow)). Vladimir |
From: William S F. <ws...@fu...> - 2013-02-10 14:12:21
|
On 09/02/13 18:43, Vladimir Kalinin wrote: >>>>> Hi, >>>>> >>>>> As it was discussed earlier, not all the target languages support the notion >>>>> of nested classes. Therefore, there should be introduced some feature, >>>>> like %feature ("directors"), that will affect nested classes handling. >>>>> >>>>> I propose a feature "nested_classes" with 3 modes, emulating old and enabling >>>>> new nested classes support. >>>>> Suppose we have a following declaration: >>>>> >>>>> struct Outer { >>>>> struct Nested { >>>>> int val; >>>>> } data; >>>>> }; >>>>> >>>>> Then %feature ("nested_classes", "ignore") will skip nested classes, like it >>>>> was done previously by default and produce a proxy >>>>> >>>>> public class Outer {} >>>>> >>>>> >>>>> %feature ("nested_classes", "flatten") - move nested classes to the >>>>> namespace containing the outer class. Result will look like >>>>> >>>>> public class Nested { public int val; } >>>>> public class Outer { public Nested data;} >>>>> >>>>> >>>>> %feature ("nested_classes", "default") - handle nested classes >>>>> normally, will result in >>>>> >>>>> public class Outer { >>>>> public class Nested { >>>>> int val; >>>>> } >>>>> public Nested data; >>>>> } >>>>> >>>>> >>>>> Perhaps there also may be something like %feature ("nested_classes", >>>>> "rename") which works like "flatten" but prepends outer class name to >>>>> the generated proxy class name: >>>>> >>>>> public class Outer_Nested { public int val; } >>>>> public class Outer { public Outer_Nested data;} >>>>> >>>>> >>>>> This feature may be inserted in a language-specific .swg file to >>>>> change the default behaviour, when the necessary changes are made in >>>>> the language module. >>>>> >>>>> Any suggestions? >>>>> >>>> I think this is a good set of proposals, but with a couple of tweaks. >>>> >>>> Having two ways to ignore a class %ignore and %feature("nested", >>>> "ignore") is confusing, especially when both are defined (bearing in >>>> mind that %ignore is just a form of %rename). So let's keep %ignore as >>>> the way to ignore the nested class. I think that the nested classes must >>>> be properly added into the symbol table for this to work, but I'd expect >>>> that to happen with your new work. A new predicate could be introduced >>>> for nested classes (see %rename predicates in swig.swg). I suggest >>>> %$isnested, so then all nested structs could be ignored like this: >>>> >>>> %rename("$ignore", %$isnested); >>>> >>>> plus more powerful targeted %rename'ing. >>>> >>>> That then leaves two different modes for the nested/nested_class >>>> feature. The feature could then be a simple feature flag, where the >>>> default is as you describe and if the feature is turned on it would turn >>>> on the flattening mode. %ignore would override both. A short concise >>>> name for the feature is needed, maybe %feature("flatnested"), also as a >>>> macro called %flatnested. BTW, the convention is not to use underscores >>>> in feature names. %rename should also allow one to change the name from >>>> the default flatnested name. >>>> >>> >>> Ok, thanks for the comments. To summarize: >>> >>> %$isnested predicate should be be defined, perhaps like this >>> (I'm not en expert on matching syntax, any suggestions are welcome): >>> >>> %define %$and "and" %enddef >>> %define %$isnested "match$nodeType"="class" %$and "match$parentNode$nodeType"="class" %enddef >>> >> I'm not too familiar with these but it looks like you don't need the >> '%$and' as I think the logical and is used when specifying more than >> one. I tried experimenting quickly but couldn't get match$parentNode to >> work even in %$innamespace. Something to sort out later. I havn't looked >> to see how you mark classes as nested in each node, but if you have >> added a 'nested' flag in the class node, then: >> >> %define %$isnested "match$nested"="1" %enddef >> > I was unable to make the macro work, but the direct approach works ok: > %rename("$ignore", match$nested="1") ""; Strange, take a look at the preprocessed output when using the macro via 'swig -E'. > >>> >>> %feature("flatnested") - tuns on "unnesting" of classes in the parse >>> tree. >>> >>> But, would it not cause a problem for all the language modules if >>> default behaviour would be to handle nested classes as nested? >>> (So that to achieve the current default, all the language .swg files >>> should include %ignore statement)) >>> >> The nested implementation would need to be done by each language module. >> The Language class could decide whether to suppress the nested class >> code generation for a target language depending on whether or not the >> target language has registered if it supports nested classes. If a >> language module has not registered then a "feature:ignore" would be >> added and a warning message emitted. You could implement it like >> Language::extraDirectorProtectedCPPMethodsRequired() >> > > I called the new method "Language::nestedClassesSupported()" > Perfect. > Have you any suggestion about where to put nested classes > postprocessing implementation? I currently placed it at the end of the typepass.cxx, > because it is somewhat related to the type system. There will > be ~400 lines of code (naming of unnamed structures for C and flattening > transformation for C++ (the first is done, and the second I hope to > finish tomorrow)). So this is the stage that modifies the parse tree to 'move' the nested classes from being nested to global. I was kind of thinking we could do with an additional parse stage after cparse and before TypePass. This stage could manipulate/modify/transform the parse tree as needed for nested classes and possibly in other areas too, although I can't think of anything right now. I think you'll need to do this before TypePass because you'll need all the processing done in TypePass for additional structs that have been added. As for names for this extra stage, I don't know, maybe Manipulate? I'd envisage no additions/modifications to the C symbol tables after this new stage (except the addition of the default constructor/destructors and copy constructors added in Allocate). Currently typepass messes around with the symbol tables for templates and I reckon it is the cause of a number of subtle type system bugs which I hope to rectify by doing this instead in cparse. Dave Beazley, do you have any thoughts on an additional parse stage? William |
From: Vladimir K. <vka...@op...> - 2013-02-10 14:57:50
|
>> Have you any suggestion about where to put nested classes >> postprocessing implementation? I currently placed it at the end of the typepass.cxx, >> because it is somewhat related to the type system. There will >> be ~400 lines of code (naming of unnamed structures for C and flattening >> transformation for C++ (the first is done, and the second I hope to >> finish tomorrow)). > So this is the stage that modifies the parse tree to 'move' the nested > classes from being nested to global. I was kind of thinking we could do > with an additional parse stage after cparse and before TypePass. This > stage could manipulate/modify/transform the parse tree as needed for > nested classes and possibly in other areas too, although I can't think > of anything right now. I think you'll need to do this before TypePass > because you'll need all the processing done in TypePass for additional > structs that have been added. As for names for this extra stage, I don't > know, maybe Manipulate? > > I'd envisage no additions/modifications to the C symbol tables after > this new stage (except the addition of the default > constructor/destructors and copy constructors added in Allocate). > Currently typepass messes around with the symbol tables for templates > and I reckon it is the cause of a number of subtle type system bugs > which I hope to rectify by doing this instead in cparse. > Actually it turned out that it would be better if this transformation takes place after typepass stage, because otherwise nested classes are not visible in the parent scope. Of course part of the typepass functionality may be copy-pasted to the flattening code, but I see no reason for that. The flattening itself happens to be trivial in that case - just pull the tree nodes from one place and drop to another. Naming unnamed C structures was a lot more challenging task. Note that in C mode flattening is not necessary because all the structures are automatically put in the global scope (which corresponds to the absence of the "name scope" notion in pure C) Naming of the C structures takes place before typepass, because name visibility is not an issue, but the name itself is expected to be present at the typepass stage. You can see the current state at https://github.com/wkalinin/swig.git Currently it passes only csharp test suite, I did not test other languages yet. (Going to test Java this night.) BTW, I would appreciate some convoluted test of the class nesting, because my imagination is severely damaged by the years of writing portable highly transparent code ) |