Messages

1

Suggestions and Requests / Declared and Referenced Namespace

« on: May 09, 2003, 06:09:00 am »

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.

Without this feature, it appears that there may be significant consequences for generated code, if an external supplier of classes revises their external class library.

There are two aspects to consider:
1. the declaration of new 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.  

 Absolute:  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

 Relative:  Ni.Ni+1. ... .Nj.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 Relative:, which is covered further below).

In the 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 relative form.

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 SomeClass instances. 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.

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 (different) SomeClass spelled the same way.

This is a compile-time error.

A Solution
----------------

A 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. The appropriate namespace declarations are emitted, before the class declaration is emitted.

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 sufficient relative and / or absolute namespace prefixes for class references to ensure that the reference is unambiguous. Any generated reference to SomeClass must carry sufficient namespace prefix to identify uniquely to a Namespace Referencing Root.

For example, The System.xxx namespaces 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, with potentially significant consequences.

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.

For example, you would probably always set System as a namespace referencing root, so that any reference to any System.xxx.SomeClass would always be generated as an absolute System.xxx.SomeClas reference. That way, you can be sure that any locally declared SomeClass will not come into conflict with a (future) System.xxx.SomeClass that Microsoft might release.

For another example, you would probably always set any other externally defined namespace whose classes you import and use as a namespace referencing root. That way, you can be sure that any locally declared SomeClass will not come into conflict with a (future) External.xxx.SomeClass when the external supplier revises their delivered class library.

Alternative (and perhaps cleaner) solutions may exist, and perhaps I missed something and these solutions are already there. If so, could you point me in the right direction?

Thanks
Rainer

2

General Board / How to create a partitition with a divider

« on: December 07, 2004, 10:18:30 am »

There is probably a simple answer to this but I have not found it.

When I first create a partition in my activity diagram it is a single horizontal box that looks like a datastore on a DFD.

I'd like to insert a horizontal dividing line into the partition with the appropriate labels down the left hand edge, as shown in the partition diagram in the EA User Guide?

There does not seem to be anything under the right-click context menu to do this. How do I do this?

Thanks
Rainer

3

General Board / Reverse engineering C# int[][]

« on: April 01, 2004, 12:08:38 pm »

When reverse engineering a C# int[][] attribute of a class, the model constructed appears to indicate that this is an int[] rather than an int[][].

Fixing it up in the model to int[][] and then forward engineering it again seems to work fine.

Is this a bug in EA reverse engineering?

4

General Board / Re: C# Struct implementing interfaces

« on: March 11, 2004, 07:15:15 am »

Thanks, Ben. That did the trick.

Rainer

5

General Board / C# Struct implementing interfaces

« on: March 09, 2004, 01:05:46 pm »

I forward engineer from EA structs (struct stereotype as opposed to a class). My structs have attributes, and also implement one or more interfaces.

When I reverse engineer a struct such as

internal struct MyStruct : ICompare
{
     internal int i1;
     internal int i2;

     int CompareTo(object obj){
           return i1 - ((MyStruct)obj).i1;
     }
}

it works fine, but then when I forward engineer that again, the Interface being implemented disappears, ie. the forward engineering produces:

internal struct MyStruct
{
     internal int i1;
     internal int i2;

     int CompareTo(object obj){
           return i1 - ((MyStruct)obj).i1;
     }
}


Any ideas?

Rainer

6

General Board / Re: Using <NameSpace>

« on: April 29, 2003, 05:33:25 pm »

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