Difference between revisions of ".NET Namespace Generation"
 
(2 intermediate revisions by the same user not shown)
Line 15: Line 15:
 
# Use Cluster Name as Namespace ('''UCNN'''): If specified, cluster name will be part of the namespace.
 
# Use Cluster Name as Namespace ('''UCNN'''): If specified, cluster name will be part of the namespace.
 
# Use Recursive Cluster Name as Namespace ('''URCNN'''): If specified, then the path to the class will be part of the namespace.
 
# Use Recursive Cluster Name as Namespace ('''URCNN'''): If specified, then the path to the class will be part of the namespace.
 +
# .NET Naming Convention: Updates unchanged Eiffel classes and clusters names to follow the .NET naming convention.
  
−
To make things clearer here is all the possible combinations and their results:
+
To make things clearer here is all the possible combinations for the first three options and their results:
 
# '''NN''' set to N: N.A, N.B and N.C
 
# '''NN''' set to N: N.A, N.B and N.C
 
# '''UCNN''' set to True: root.A, root.B and root.C
 
# '''UCNN''' set to True: root.A, root.B and root.C
Line 40: Line 41:
  
 
==Mixing With Libraries==
 
==Mixing With Libraries==
−
Once options are set at a library level, they cannot be overridden. The compiler will use the library settings to generate the namespaces.
+
Once options are set at a library level, they cannot be overridden. The compiler will use the library settings to generate the namespaces. This is why the option is non-functioning/disallowed for library, precompile or assembly nodes in the configuration file.
 +
 
 +
===Why?===
 +
Suppose we have the following system:
 +
target a
 +
  library l1
 +
  library l2
 +
  library l3
 +
 +
target library l2
 +
  library l3
 +
 
 +
If both target '''a''' and '''library l2''' were to specify a different namespace, it would be hard to know which one should take precedence. Let's assume it is '''a''', then if library '''l2''' relies on a certain namespace for '''l3''' then library '''l2''' might stop working properly, which would be bad.

Latest revision as of 09:39, 19 March 2007

Reference example

Assume the following directory structure: 

cluster root
  class A
  directory d1
    class B
  directory d2
    class C

List of Settings

Target options

At this level you can specify the following:

  1. .NET Namespace (NN): Namespace in which all classes will be put in.
  2. Use Cluster Name as Namespace (UCNN): If specified, cluster name will be part of the namespace.
  3. Use Recursive Cluster Name as Namespace (URCNN): If specified, then the path to the class will be part of the namespace.
  4. .NET Naming Convention: Updates unchanged Eiffel classes and clusters names to follow the .NET naming convention.

To make things clearer here is all the possible combinations for the first three options and their results:

  1. NN set to N: N.A, N.B and N.C
  2. UCNN set to True: root.A, root.B and root.C
  3. URCNN set to True: A, d1.B and d2.C
    1. UCNN and URCNN set to True: root.A, root.d1.B and root.d2.C
  4. NN set to N:
    1. UCNN set to True: N.root.A, N.root.B and N.root.C
    2. URCNN set to True: N.A, N.d1.B and N.d2.C
      1. UCNN and URCNN set to True: N.root.A, N.root.d1.B and N.root.d2.C

Cluster option

At this level you can only specify the namespace of the cluster. When set, it will ignore the UCNN option set at the target where the cluster belongs.

For example setting the namespace for cluster root to be DotnetRoot will result in:

  1. NN set to N: N.DotnetRoot.A, N.DotnetRoot.B and N.DotnetRoot.C
  2. UCNN set to True: DotnetRoot.A, DotnetRoot.B and DotnetRoot.C
  3. URCNN set to True: DotnetRoot.A, DotnetRoot.d1.B and DotnetRoot.d2.C
    1. UCNN and URCNN set to True: DotnetRoot.A, DotnetRoot.d1.B and DotnetRoot.d2.C
  4. NN set to N:
    1. UCNN set to True: N.DotnetRoot.A, N.DotnetRoot.B and N.DotnetRoot.C
    2. URCNN set to True: N.DotnetRoot.A, N.DotnetRoot.d1.B and N.DotnetRoot.d2.C
      1. UCNN and URCNN set to True: N.DotnetRoot.A, N.DotnetRoot.d1.B and N.DotnetRoot.d2.C

Mixing With Libraries

Once options are set at a library level, they cannot be overridden. The compiler will use the library settings to generate the namespaces. This is why the option is non-functioning/disallowed for library, precompile or assembly nodes in the configuration file.

Why?

Suppose we have the following system: 

target a
  library l1
  library l2
  library l3

target library l2
  library l3

If both target a and library l2 were to specify a different namespace, it would be hard to know which one should take precedence. Let's assume it is a, then if library l2 relies on a certain namespace for l3 then library l2 might stop working properly, which would be bad.

Retrieved from "https://dev.eiffel.com/index.php?title=.NET_Namespace_Generation&oldid=7670"