Issue 2922: Collections of imported DataTypes can cause name clashes (mof-rtf)
Source: DSTC (Dr. Stephen Crawley, nobody)
Nature: Uncategorized Issue
Severity: 
Summary: If a Package declares a DataType with a given name and imports
another Package that also declares a DataType with the same name
the IDL templates can generate uncompilable IDL for the collections 
typedefs if both are required.
Resolution: see above
Revised Text: In Section 5.7.2, replace the following paragraphs: 

  "The declarations for collection types will appear in one of three places ... must only be generated if they are needed within the IDL for the current outermost Package." 

with 

  "Declarations for the collection types appear following the IDL declaration for a DataType or the forward IDL declaration for a Class.  Declarations for collection types for technology neutral and CORBA specific primitive data types appear in the "PrimitiveTypes" and "CorbaIdlTypes" modules  respectively." 

In section 5.8.2, delete the following from the Package module template: 

  "// if this Package is a "top-level" Package, generate any collection types 
   // for built-in types that are required by the IDL for this Package and 
   // its contents 
   typedef sequence < <BuiltinType> > <BuiltinTypeName><CollectionKind>; 

   // if the Package has superPackages, generate any collection 
   // types for inherited types that are required by the IDL for this Package 
   // and its contents 
   typedef sequence < <InheritedType> > <InheritedType><CollectionKind>; 

   // if the Package has Imports, generate any collection types for 
   // imported or clustered types that are required by the IDL for this Package 
   // and its contents 
   typedef sequence < <ImportedType> > <ImportedType><CollectionKind>;" 

In section 5.8.2, delete the following: 

  "The first group of declarations within the module are the sequence type declarations for collection types: 

   *  If the M2-level Package is a top-level Package, the template generates collection types for the MOF built-in types as required. 

   *  If the M2-level Package has superPackages, the template generates collection types for inherited Classes and DataTypes as required. 

   *  If the M2-level Package has Imports, the template generates collection types for any Classes and DataTypes in the imported or clustered Packages. 

   Note:  Collection types should only be generated if they are going to be used within the current outermost module." 

Change "After the collection types, the ..." to "The ..." 

In section 5.8.5, change the following comment in the template: 

   "// generate type declarations for any collections of this Class that 
    // will be used by the IDL being generated" 

to 

   "// generate type declarations for any collections of this Class" 

In the following description, change 

   "If any collection types for this Class are required, their declarations  should follow the forward declarations. 

    Note: Collection types should only be generated if they are going to be used within the current outermost module." 

to 

   "Collection type declarations for the Class follow the forward declarations." 

In section 5.8.14, change the text (as amended by 2198) from: 

   "*  If the outermost enclosing Package for the DataType contains a use of the DataType in a non-[1..1] Attribute or Parameter, the template generates appropriate synthesized collection types according to Section 5.7.2, "Generation Rules for Collection Types," on page 5-41. 

    Note:  In the interests of IDL footprint size, the DataType template should only generate collection type declarations if they are needed." 

to: 

   "*  The template generates collection types according to Section 5.7.2, "Generation Rules for Collection Types," on page 5-41." 

In 3.9.1, change the IDL for the PrimitiveTypes module (added by 2198) to be as follows: 

   #pragma prefix "org.omg.mof" 
   module PrimitiveTypes { 
     typedef sequence < boolean > BooleanBag; 
     typedef sequence < boolean > BooleanSet; 
     typedef sequence < boolean > BooleanList; 
     typedef sequence < boolean > BooleanUList; 
     typedef sequence < long > LongBag; 
     typedef sequence < long > LongSet; 
     typedef sequence < long > LongList; 
     typedef sequence < long > LongUList; 
     typedef sequence < long long > LongLongBag; 
     typedef sequence < long long > LongLongSet; 
     typedef sequence < long long > LongLongList; 
     typedef sequence < long long > LongLongUList; 
     typedef sequence < float > FloatBag; 
     typedef sequence < float > FloatSet; 
     typedef sequence < float > FloatList; 
     typedef sequence < float > FloatUList; 
     typedef sequence < double > DoubleBag; 
     typedef sequence < double > DoubleSet; 
     typedef sequence < double > DoubleList; 
     typedef sequence < double > DoubleUList; 
     typedef sequence < wstring > WStringBag; 
     typedef sequence < wstring > WStringSet; 
     typedef sequence < wstring > WStringList; 
     typedef sequence < wstring > WStringUList; 

     interface PrimitiveTypesPackage : Reflective::RefPackage { }; 

     interface PrimitiveTypesPackageFactory { 
       PrimitiveTypesPackage create_primitive_types_package() 
  raises (Reflective::MofError); 
     }; 
  }; 

In 5.3.1, change the IDL for the CorbaIdlTypes module (added by 2198) to be as follows: 

   #pragma prefix "org.omg.mof" 
   module CorbaIdlTypes { 
     typedef sequence < octet > OctetBag; 
     typedef sequence < octet > OctetSet; 
     typedef sequence < octet > OctetList; 
     typedef sequence < octet > OctetUList; 
     typedef sequence < short > ShortBag; 
     typedef sequence < short > ShortSet; 
     typedef sequence < short > ShortList; 
     typedef sequence < short > ShortUList; 
     typedef sequence < unsigned short > UShortBag; 
     typedef sequence < unsigned short > UShortSet; 
     typedef sequence < unsigned short > UShortList; 
     typedef sequence < unsigned short > UShortUList; 
     typedef sequence < unsigned long > ULongBag; 
     typedef sequence < unsigned long > ULongSet; 
     typedef sequence < unsigned long > ULongList; 
     typedef sequence < unsigned long > ULongUList; 
     typedef sequence < unsigned long long > ULongLongBag; 
     typedef sequence < unsigned long long > ULongLongSet; 
     typedef sequence < unsigned long long > ULongLongList; 
     typedef sequence < unsigned long long > ULongLongUList; 
     typedef sequence < long double > ULongDoubleBag; 
     typedef sequence < long double > ULongDoubleSet; 
     typedef sequence < long double > ULongDoubleList; 
     typedef sequence < long double > ULongDoubleUList; 
     typedef sequence < string > StringBag; 
     typedef sequence < string > StringSet; 
     typedef sequence < string > StringList; 
     typedef sequence < string > StringUList; 
     typedef sequence < char > CharBag; 
     typedef sequence < char > CharSet; 
     typedef sequence < char > CharList; 
     typedef sequence < char > CharUList; 
     typedef sequence < wchar > WCharBag; 
     typedef sequence < wchar > WCharSet; 
     typedef sequence < wchar > WCharList; 
     typedef sequence < wchar > WCharUList; 

     interface CorbaIdlTypesPackage : Reflective::RefPackage { }; 

     interface CorbaIdlTypesPackageFactory { 
       CorbaIdlTypesPackage create_corba_idl_types_package() 
  raises (Reflective::MofError); 
     }; 
  }; 

Propagate changes to Appendix B. 


Actions taken:
October 5, 1999: received issue
December 3, 2001: closed issue
Discussion: 
Solve this problem by changing the IDL mapping so that the FooBag, FooSet, FooList and FooUList typedefs appear after the declaration of Foo, whether or not they are used locally.  Collection typedefs for the types defined in PrimitiveTypes and CorbaIdlTypes are added to the respective IDL models. 


End of Annotations:=====
X-Mailer: exmh version 2.1.0 09/18/1999
To: mof-rtf@omg.org, issues@omg.org
Subject: Collections of imported DataTypes can cause name clashes
Mime-Version: 1.0
Date: Tue, 05 Oct 1999 17:32:17 +1000
From: Stephen Crawley <crawley@dstc.edu.au>
Content-Type: text/plain; charset=us-ascii
X-UIDL: L(pd9;pnd9^P)e9Oh~!!


If a Package declares a DataType with a given name and imports
another Package that also declares a DataType with the same name
the IDL templates can generate uncompilable IDL for the collections 
typedefs if both are required.

Here is an example (in MODL) that illustrates the problem:

  package P1 {
    typedef string Foo;   // << -- or any other DataType called Foo
...
  };

  package P2 {
    import P1;

    typedef long Foo;

    class C {
      attribute set [0..*] of Foo a1;         // <<-- these attrs
require the
      attribute set [0..*] of ::P1::Foo a2;   // generation of
collection types
    };
  };

When you apply the templates to P2 you will get an IDL module that
contains
the following declarations:

  typedef sequence < Foo > FooSet;
  typedef sequence < ::P1::Foo > FooSet;  // <<-- note name clash

I can't think of a neat fix for this.  On the other hand, it is a
rather
artificial case ... and in reality the meta-modeller can easily fix it
by
declaring one of the DataTypes with another name, or by using an
"alternative 
name" Tag.

My suggested resolution is to just document the anomaly in the IDL
generation
preconditions section.

-- Steve



X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: mof-rtf@omg.org
Subject: Re: Issue 2922: Collections of imported DataTypes can cause
name clashes
Mime-Version: 1.0
Date: Mon, 25 Jun 2001 15:02:46 +1000
From: Stephen Crawley <crawley@dstc.edu.au>
X-Scanned-By: MIMEDefang 1.0
(http://www.roaringpenguin.com/mimedefang/)
Content-Type: text/plain; charset=us-ascii
X-UIDL: 7!$!!`*2e9BW=e97'n!!

> Source: DSTC (Dr. Stephen Crawley, crawley@dstc.edu.au)
> Nature: Uncategorized Issue
> Severity: 
> Summary: If a Package declares a DataType with a given name and
> imports 
> another Package that also declares a DataType with the same
> name the IDL templates can generate uncompilable IDL for the
> collections
> typedefs if both are required.

Discussion:

This somewhat obscure case is a result of trying to get the IDL
mapping
to generate collection types only when needed.  Unfortunately, it
doesn't work in all cases; e.g. when collection types are needed in
two
more importing or inheriting packages, you actually get multiple
copies
of the typedefs.  [See also old issue 1498.]  In addition, this
"cleverness" makes IDL and code generation significantly more complex.

Given that MOF 1.4 is making changes that will significantly impact on
IDL and code generation, I'd like us to take this opportunity to
simplify
the IDL generation rules as follows:

  1)  After each DataType's IDL type declaration, add the four
      collection
      typedefs ... irrespective of whether or not the current Package
      uses
      them.

  2)  After each Classes's IDL forward declaration, add the four
      collection
      typedefs ... irrespective of whether or not the current Package
      uses
      them.

  3)  Define a new IDL module called "PrimitiveTypes" that contains
      the
      collection typedefs for all PrimitiveTypes and AliasTypes
      defined
      therein.

  4)  If there is an "ExtendedDataTypes" Package do the same for that.

This will achieve two things:

  1)  It simplify the IDL mapping and generators that depend on it in
      some way; e.g. IDL generators, server generators and generators
      for clients (e.g. XMI producers / consumers) that use the IDL.

  2)  It will remove the anomaly that this issue refers to.

Comments?

-- Steve



X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: mof-rtf@omg.org
Subject: Re: Issue 2922: Collections of imported DataTypes can cause
name clashes
Mime-Version: 1.0
Date: Mon, 02 Jul 2001 16:23:01 +1000
From: Stephen Crawley <crawley@dstc.edu.au>
X-Scanned-By: MIMEDefang 1.0
(http://www.roaringpenguin.com/mimedefang/)
Content-Type: text/plain; charset=us-ascii
X-UIDL: J>E!!&*+e9-*B!!-E/!!


There was no feedback on my previous email on 2922, so here's the
proposed
resolution.

> Source: DSTC (Dr. Stephen Crawley, crawley@dstc.edu.au)
> Nature: Uncategorized Issue
> Severity: 
> Summary: If a Package declares a DataType with a given name and
> imports 
> another Package that also declares a DataType with the same
> name the IDL templates can generate uncompilable IDL for the
> collections
> typedefs if both are required.

Proposed Resolution:

Solve this problem by changing the IDL mapping so that the FooBag,
FooSet,
FooList and FooUList typedefs appear after the declaration of Foo,
whether 
or not they are used locally.  Collection typedefs for the types
defined in
PrimitiveTypes and CorbaIdlTypes are added to the respective IDL
models.

Proposed Revised text:

In Section 5.7.2, replace the following paragraphs:

  "The declarations for collection types will appear in one of three
  places:
  ... must only be generated if they are needed within the IDL for the 
  current outermost Package."

with

  "Declarations for the collection types appear following the IDL
  declaration
   for a DataType or the forward IDL declaration for a Class.
  Declarations
   for collection types for technology neutral and CORBA specific
  primitive
   data types appear in the "PrimitiveTypes" and "CorbaIdlTypes"
  modules 
   respectively."

In section 5.8.2, delete the following from the Package module
template:

  "// if this Package is a "top-level" Package, generate any
  collection types
   // for built-in types that are required by the IDL for this Package
  and 
   // its contents
   typedef sequence < <BuiltinType> >
  <BuiltinTypeName><CollectionKind>;

   // if the Package has superPackages, generate any collection
   // types for inherited types that are required by the IDL for this
   Package
   // and its contents
   typedef sequence < <InheritedType> >
   <InheritedType><CollectionKind>;

   // if the Package has Imports, generate any collection types for
   // imported or clustered types that are required by the IDL for
   this Package
   // and its contents
   typedef sequence < <ImportedType> >
   <ImportedType><CollectionKind>;"

In section 5.8.2, delete the following:

  "The first group of declarations within the module are the sequence
  type 
   declarations for collection types:

   *  If the M2-level Package is a top-level Package, the template
      generates 
      collection types for the MOF built-in types as required. 

   *  If the M2-level Package has superPackages, the template
      generates 
      collection types for inherited Classes and DataTypes as
      required.

   *  If the M2-level Package has Imports, the template generates
      collection 
      types for any Classes and DataTypes in the imported or clustered
      Packages.
  
   Note:  Collection types should only be generated if they are going
   to be 
   used within the current outermost module."

Change "After the collection types, the ..." to "The ..."

In section 5.8.5, change the following comment in the template:

   "// generate type declarations for any collections of this Class
   that
    // will be used by the IDL being generated"

to

   "// generate type declarations for any collections of this Class"

In the following description, change

   "If any collection types for this Class are required, their
   declarations 
    should follow the forward declarations.

    Note: Collection types should only be generated if they are going
    to be 
    used within the current outermost module."

to

   "Collection type declarations for the Class follow the forward
   declarations."

In section 5.8.14, change the text (as amended by 2198) from:

   "*  If the outermost enclosing Package for the DataType contains a
   use 
       of the DataType in a non-[1..1] Attribute or Parameter, the
   template
       generates appropriate synthesized collection types according to
       Section 5.7.2, "Generation Rules for Collection Types," on page
   5-41.

    Note:  In the interests of IDL footprint size, the DataType
    template 
    should only generate collection type declarations if they are
    needed."

to:

   "*  The template generates collection types according to
       Section 5.7.2, "Generation Rules for Collection Types," on page
       5-41."

In 3.9.1, change the IDL for the PrimitiveTypes module (added by 2198)
to
be as follows:

   #pragma prefix "org.omg.mof"
   module PrimitiveTypes {
     typedef sequence < boolean > BooleanBag;
     typedef sequence < boolean > BooleanSet;
     typedef sequence < boolean > BooleanList;
     typedef sequence < boolean > BooleanUList;
     typedef sequence < long > LongBag;
     typedef sequence < long > LongSet;
     typedef sequence < long > LongList;
     typedef sequence < long > LongUList;
     typedef sequence < long long > LongLongBag;
     typedef sequence < long long > LongLongSet;
     typedef sequence < long long > LongLongList;
     typedef sequence < long long > LongLongUList;
     typedef sequence < float > FloatBag;
     typedef sequence < float > FloatSet;
     typedef sequence < float > FloatList;
     typedef sequence < float > FloatUList;
     typedef sequence < double > DoubleBag;
     typedef sequence < double > DoubleSet;
     typedef sequence < double > DoubleList;
     typedef sequence < double > DoubleUList;
     typedef sequence < wstring > WStringBag;
     typedef sequence < wstring > WStringSet;
     typedef sequence < wstring > WStringList;
     typedef sequence < wstring > WStringUList;

     interface PrimitiveTypesPackage : Reflective::RefPackage { };

     interface PrimitiveTypesPackageFactory { 
       PrimitiveTypesPackage create_primitive_types_package()
       raises (Reflective::MofError);
     };
  };

In 5.3.1, change the IDL for the CorbaIdlTypes module (added by 2198)
to be 
as follows:

   #pragma prefix "org.omg.mof"
   module CorbaIdlTypes {
     typedef sequence < octet > OctetBag;
     typedef sequence < octet > OctetSet;
     typedef sequence < octet > OctetList;
     typedef sequence < octet > OctetUList;
     typedef sequence < short > ShortBag;
     typedef sequence < short > ShortSet;
     typedef sequence < short > ShortList;
     typedef sequence < short > ShortUList;
     typedef sequence < unsigned short > UShortBag;
     typedef sequence < unsigned short > UShortSet;
     typedef sequence < unsigned short > UShortList;
     typedef sequence < unsigned short > UShortUList;
     typedef sequence < unsigned long > ULongBag;
     typedef sequence < unsigned long > ULongSet;
     typedef sequence < unsigned long > ULongList;
     typedef sequence < unsigned long > ULongUList;
     typedef sequence < unsigned long long > ULongLongBag;
     typedef sequence < unsigned long long > ULongLongSet;
     typedef sequence < unsigned long long > ULongLongList;
     typedef sequence < unsigned long long > ULongLongUList;
     typedef sequence < long double > ULongDoubleBag;
     typedef sequence < long double > ULongDoubleSet;
     typedef sequence < long double > ULongDoubleList;
     typedef sequence < long double > ULongDoubleUList;
     typedef sequence < string > StringBag;
     typedef sequence < string > StringSet;
     typedef sequence < string > StringList;
     typedef sequence < string > StringUList;
     typedef sequence < char > CharBag;
     typedef sequence < char > CharSet;
     typedef sequence < char > CharList;
     typedef sequence < char > CharUList;     
     typedef sequence < wchar > WCharBag;
     typedef sequence < wchar > WCharSet;
     typedef sequence < wchar > WCharList;
     typedef sequence < wchar > WCharUList;

     interface CorbaIdlTypesPackage : Reflective::RefPackage { };

     interface CorbaIdlTypesPackageFactory { 
       CorbaIdlTypesPackage create_corba_idl_types_package()
       raises (Reflective::MofError);
     };
  };

Propagate changes to Appendix B.