Ambiguous type names in generated code when using eSubpackages about nmf HOT 4 CLOSED

Hi Lukas,

first of all, thanks for your interest in NMF.

The rationale behind the NMF code generator is that the generated code should be as polished as possible. This is why the types are not generated with using statements. I am aware that this may in some cases cause naming conflicts, but so far, I have almost ignored them.

The NMF code generator is built on top of the CodeDOM model, which means that it generates a model of the code instead of the code itself as a string. The reason for this is the support of multiple .NET languages, though I never really tried anything else than C#. What the NMF code generator does is to store the namespace of a type reference as user data of a CodeDOM type reference. Before the code model is printed, the generator tries to identify name conflits in order to decide whether to generate the fully qualified type or just the type name. However, that feature was never truly tested and rather implemented as a hack, I am not really suprised that you found a bug in there, to be honest.

There are multiple options to proceed here, I would not like to generally generate all type references with the full type name, but one thing that would be sensible to support is to switch to this behavior via a command-line parameter. Alternatively or additionally, one could try to identify the bug in the name clash detection.

Unfortunately, I am currently not able to give you pointers, I will try to provide anytime today in the evening or witin the next days.

Best regards,

Georg

from nmf.

Hi, thanks for the quick response!

I agree that the verbose type names with namespaces should not be the default, but it would be awesome if we could implement a switch or fix the detection mechanism.

I am currently working through the code generation and already understand a bit more. In my specific example, I found that the Reference2Property class creates the property that creates the error, but I can't find where the type of the CodeMemberProperty is set.

from nmf.

I think I managed to fix this. "NMF.Models.Meta" was missing in Meta2ClassesTransformation.DefaultSystemImports, so namespace conflicts with types in that namespace were not detected.

I sent you a pull request with the fix.

Thanks again for your quick help! Without knowing that there is a namespace conflict detection mechanism, it would have taken me a long time to find a fix.

from nmf.

Fixed with e49158a (#18)

from nmf.