Namespaces and C# Code Generation
------------------------------------
An EA improvement appears needed to enhance the use of Namespaces in C# and to avoid hand-fixup of generated code. The following analysis of the issue should help to understand and perhaps clarify things.
There are two aspects to consider:
1. the declaration of classes in namespaces, and
2. the reference to previously declared classes.
Declaration of a class happens once, but reference to a class happens many times.
Class Declaration
-----------------
Declaration of a class always happens in an absolute namespace, eg.
A. N1.N2. ... .Nj.SomeClass.
Current EA code generation options permit setting a package Ni as namespace root, which causes the generated declaration to take a relative form
R. Ni+1.Ni+2. ... .Nj.SomeClass
The A. form is an absolute namespace-qualified declaration of SomeClass. (Where N1 is not absolute but is implied as being in or relative to another namespace, we really have a relative qualification of form R., which is covered by R. below).
The R. form is a relative namespace-qualified declaration of SomeClass. There is always some assumed further absolute namespace prefix, which EA does not generate. The EA "Set as Namespace Root" is used to accomplish this. Alternatively, the user leaves the prefix package string out of their EA model, and sets "Logical Model" as namespace root.
The reason for the namespace prefix of SomePrefix.SomeClass is to distinguish it from SomeOtherPrefix.SomeClass, where SomeClass has the same spelling. That is why namespaces where invented, here and in other areas such as Xml. The distinct prefixes disambiguate the ambiguous SomeClass spelling into a specific class with a uniquely identified namespace prefix.
Class Reference
---------------
Class reference happens many times, for example in multiple declarations of class instances of SomeClass. In order to save typing, C# provides the "Using SomePrefix;" construct so that you do not have to type the full SomePrefix.SomeClass for every class reference. This use makes the SomeClass reference relative to the Using identified namespace prefix(es).
The Problem
-----------
Unfortunately, overuse of the "Using" feature can introduce ambiguities where SomeClass can resolve to different SomePrefix namespaces in which SomeClass has been declared. Consider
Using Namespace1;
Using Namespace2;
public MyClass: SomeClass ...
where both Namespace1 and Namespace2 declare a SomeClass.
This generates a compile-time error.
The Solution
------------
The solution is to disambiguate the SomeClass reference by providing sufficient (relative or absolute) namespace prefix to achieve unique identification to the desired class in the desired namespace.
EA provides the "Set as Namespace Root" mechanism as a control that operates on the declarative side of the code generator, and permits control of namespace prefix generation for class declaration. This is really a "Set as Namespace (Declarative) Root" control -- it controls the generation of the class declarations.
What is missing is an additional "Set as Namespace (Referencing) Root" control that permits control of namespace prefix generation for class references. This control must control both the generation of the appropriate "Using" statements, and the generation of relative and / or absolute namespace prefixes for class references. Any generated reference to SomeClass must carry sufficient namespace prefix to identify to a Namespace Referencing Root, including the Referencing Root itself.
For example, The System.xxx namespace(s) would generally not be set to be a Namespace Referencing Root(s), thereby ensuring that any generated reference to any System.xxx.SomeClass is always absolute. This is essential, since one can not be sure that Microsoft will not at some future time release a SomeClass as System.xxx.SomeClass that comes into conflict with OurNameSpacePrefix.SomeClass that we have constructed. Our code of form
Using System.xxx;
Using OurNameSpacePrefix;
... many SomeClass references ...
would break under these conditions.
Conclusion
----------
In addition to the current "Set as (Declarative) Namespace Root" control that controls the generation of declarations, it appears EA requires an additional "Set as (Referencing) Namespace Root" control that controls the generation of references. Manual code fixups are otherwise potentially required.
That's the way it seems to want to want to come together here anyways.
Alternative (and perhaps cleaner) solutions may exist, and perhaps I missed something and they are already there in some other form. If so, let me know.
Rainer
