Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - kossmann

Pages: [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 namespaces would generally not be set to be a Namespace Referencing Root(s), thereby ensuring that any generated reference to any is always absolute. This is essential, since one can not be sure that Microsoft will not at some future time release a SomeClass as that comes into conflict with OurNameSpacePrefix.SomeClass that we have constructed. Our code of form:

 Using OurNameSpacePrefix;

 ... many SomeClass references ...

would break under these conditions, with potentially significant consequences.


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 would always be generated as an absolute reference. That way, you can be sure that any locally declared SomeClass will not come into conflict with a (future) 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) 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?


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?


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?

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?


Pages: [1]