IDL4 to C# Language Mapping Avatar
  1. OMG Specification

IDL4 to C# Language Mapping — All Issues

  • Acronym: IDL4-CSHARP
  • Issues Count: 18
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
IDL4CSP11-7 The class shall implement the IEquatable interface, where T is the corresponding class name. IDL4-CSHARP 1.0 open
IDL4CSP11-8 Use of annotations as part of IDL example do not provide a clean example IDL4-CSHARP 1.0 open
IDL4CSP11-6 Use of anonymous array type in array section IDL4-CSHARP 1.0 open
IDL4CSP11-5 Sections mapped to naming schemes complicates the document IDL4-CSHARP 1.1b1 open
IDL4CSP11-4 A canonical example for sequences is missing IDL4-CSHARP 1.0 open
IDL4CSP11-3 Basic types include extended types IDL4-CSHARP 1.1b1 open
IDL4CSP11-2 Union implicit default IDL4-CSHARP 1.1b1 open
IDL4CSP-3 The specification shouldn't preclude vendors from adding additional methods to a class or struct IDL4-CSHARP 1.0a1 IDL4-CSHARP 1.0 Resolved closed
IDL4CSP-2 All generated classes and structs should implement IEquatable IDL4-CSHARP 1.0a1 IDL4-CSHARP 1.0 Resolved closed
IDL4CSP-1 A sequence member in an IDL struct should map to a read-only property IDL4-CSHARP 1.0a1 IDL4-CSHARP 1.0 Resolved closed
IDL4CSP-10 System.Collections.IList interface provides limited functionality IDL4-CSHARP 1.0a1 IDL4-CSHARP 1.0 Resolved closed
IDL4CSP-5 Do the copy and all values constructors make deep copies or shallow copies? IDL4-CSHARP 1.0a1 IDL4-CSHARP 1.0 Resolved closed
IDL4CSP-4 Typos and Inconsistencies IDL4-CSHARP 1.0a1 IDL4-CSHARP 1.0 Resolved closed
IDL4CSP-6 Resolution for name clashes with the Discriminator property name is invalid IDL4-CSHARP 1.0a1 IDL4-CSHARP 1.0 Resolved closed
IDL4CSP-7 Interface argument modifiers IDL4-CSHARP 1.0a1 IDL4-CSHARP 1.0 Resolved closed
IDL4CSP-14 Missing option in @csharp_mapping annotation to document mapping to standalone constant classes IDL4-CSHARP 1.0a1 IDL4-CSHARP 1.0 Resolved closed
IDL43-39 Use of Omg.Types IDL4-CSHARP 1.1b1 open
IDL4CSP11-1 Partial classes cannot span assemblies IDL4-CSHARP 1.1b1 open

Issues Descriptions

The class shall implement the IEquatable interface, where T is the corresponding class name.

  • Status: open  
  • Source: Objective Interface Systems ( Mr. Chuck Abbott)
  • Summary:

    This should be changed to a "may" or a "could". Shall seems overly prescriptive.

    How could a compliant implementation of Equals<T> be distinguished from Equals(Object) from the callers/users perspective?

  • Reported: IDL4-CSHARP 1.0 — Mon, 30 Aug 2021 21:22 GMT
  • Updated: Wed, 8 Sep 2021 15:00 GMT

Use of annotations as part of IDL example do not provide a clean example

  • Status: open  
  • Source: Objective Interface Systems ( Mr. Chuck Abbott)
  • Summary:

    The annotations should be covered in a separate section of the document and NOT be part of a clean, canonical example.

    Suggest:
    // IDL
    enum E

    {x, y, z}

    ;

    // C#
    public enum E

    { x, y, z }

    ;

    Also should enums inherit uint?

  • Reported: IDL4-CSHARP 1.0 — Mon, 30 Aug 2021 21:28 GMT
  • Updated: Wed, 8 Sep 2021 15:00 GMT

Use of anonymous array type in array section

  • Status: open  
  • Source: Objective Interface Systems ( Mr. Chuck Abbott)
  • Summary:

    Anonymous types should be moved to their own section

    Suggest:

    //IDL
    typedef long myLongArray[2][3];

    // C# example

  • Reported: IDL4-CSHARP 1.0 — Mon, 30 Aug 2021 21:32 GMT
  • Updated: Wed, 8 Sep 2021 15:00 GMT

Sections mapped to naming schemes complicates the document

  • Status: open  
  • Source: Objective Interface Systems ( Mr. Chuck Abbott)
  • Summary:

    Suggestion is to have one section or appendix where possible naming mappings could be covered.

    Change the IDL example naming to match the C# community expectations if that makes it easier to specify

  • Reported: IDL4-CSHARP 1.1b1 — Mon, 30 Aug 2021 21:18 GMT
  • Updated: Wed, 8 Sep 2021 14:22 GMT

A canonical example for sequences is missing

  • Status: open  
  • Source: Objective Interface Systems ( Mr. Chuck Abbott)
  • Summary:

    Beside basic types no other canonical example is included. I suggest removing the basic types and having one example.

    // IDL
    struct foo

    {...};
    typedef sequence<foo> fooSeq;

    // C#
    class fooSeq : IDL:ISequences<foo> {...}

    ;

    Something like this.

  • Reported: IDL4-CSHARP 1.0 — Mon, 30 Aug 2021 21:13 GMT
  • Updated: Wed, 8 Sep 2021 14:22 GMT

Basic types include extended types

  • Status: open  
  • Source: Objective Interface Systems ( Mr. Chuck Abbott)
  • Summary:

    Types such as sbyte and int32 are included in this section and should not be.

    These types should be moved to the extended types section.

    The section for these types is missing from the document.

  • Reported: IDL4-CSHARP 1.1b1 — Mon, 30 Aug 2021 21:09 GMT
  • Updated: Wed, 8 Sep 2021 14:21 GMT

Union implicit default

  • Status: open  
  • Source: Objective Interface Systems ( Mr. Chuck Abbott)
  • Summary:

    The section that describes the default value does not include a discussion
    of what to do when a default is not present. In this case a method called _default or
    __default should be defined to set the discriminant to a non-switched field value.
    This should be fixed before December.

  • Reported: IDL4-CSHARP 1.1b1 — Wed, 24 Mar 2021 13:57 GMT
  • Updated: Thu, 1 Apr 2021 15:55 GMT

The specification shouldn't preclude vendors from adding additional methods to a class or struct

  • Key: IDL4CSP-3
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Fernando Garcia-Aranda)
  • Summary:

    The generated code for classes and structs should be allowed to override common functions such as GetHashCode and ToString.

    It should also be allowed to implement additional interfaces in addition to IEquatable (see IDL4CSP-1).

    It should also be allowed to add additional methods, such as Clone or copy constructors.

  • Reported: IDL4-CSHARP 1.0a1 — Sun, 22 Mar 2020 20:14 GMT
  • Disposition: Resolved — IDL4-CSHARP 1.0
  • Disposition Summary:

    Allow adding additional methods and interfaces in generated types

    This resolution adds explicit phrasing that allows vendors to add additional methods and interfaces to generated types.

    The resolution of this issue shall be applied after the resolution of IDL4CSP-2.

  • Updated: Mon, 29 Mar 2021 12:23 GMT

All generated classes and structs should implement IEquatable

  • Key: IDL4CSP-2
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Fernando Garcia-Aranda)
  • Summary:

    All constructed data types should implement IEquatable:

    The example in section 7.2.4.3.1 would now look as follows:

    public class MyStruct : IEquatable<MyStruct> {
        public MyStruct() {...}
        public MyStruct(int a_long, short a_short, int[] a_long_array) {...} 
        public int a_long { get; set; }
        public short a_short { get; set; }
        public int[] a_long_array { get; set; }
    
        public bool Equals(MyStruct other)
            => a_long == other.a_long 
                 && a_short == other.a_short 
                 && a_long_array.Equals(other.a_long_array)
    }
    
  • Reported: IDL4-CSHARP 1.0a1 — Sun, 22 Mar 2020 20:13 GMT
  • Disposition: Resolved — IDL4-CSHARP 1.0
  • Disposition Summary:

    Add IEquatable interface to all generated classes

    This resoultion mandates the implementation of the IEquatable interface in all generated classes.

  • Updated: Mon, 29 Mar 2021 12:23 GMT

A sequence member in an IDL struct should map to a read-only property

  • Key: IDL4CSP-1
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Fernando Garcia-Aranda)
  • Summary:

    The spec indicates that all members of a class or struct are mapped to read-write properties, as shown in 7.2.4.3.1:

    public int a_long { get; set; }
    public short a_short { get; set; }
    public int[] a_long_array { get; set; }
    

    However sequence members (IList) should map to read-only properties.

    public IList<int> a_long_sequence { get; }
    

    Rationale: C# best practices recommend this change: https://docs.microsoft.com/en-us/visualstudio/code-quality/ca2227?view=vs-2019

    For example, a vendor may decide to use an implementation of IList that allows accessing the memory directly (via unsafe code or Span) to optimize its serialization. If end users are allowed to completely replace the list, they may inadvertently provide a different IList| implementation that the vendor code can't serialize optimally or can't handle at all.

    The same could apply to Maps.

  • Reported: IDL4-CSHARP 1.0a1 — Sun, 22 Mar 2020 20:10 GMT
  • Disposition: Resolved — IDL4-CSHARP 1.0
  • Disposition Summary:

    Making sequence members read-only properties

    This resolution transforms properties resulting from mapping IDL sequence and maps struct members into read-only properties, following the C# best practices described in the issue.

    It also introduces setters for Unions, where setting a sequence or a map would need to also update the discriminator value.

  • Updated: Mon, 29 Mar 2021 12:23 GMT

System.Collections.IList interface provides limited functionality

  • Key: IDL4CSP-10
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Fernando Garcia-Aranda)
  • Summary:

    Sequences are currently mapped to System.Collections.IList<T>, which enables vendors to roll out their own sequence implementation while maintaining compatibility with other list implementations users may use in application code. Unfortunately, unlike the interfaces we chose in language mappings like Java, IList lacks support for mechanisms to handle the internal sequence that are important to implement certain patterns. For example, IList lacks methods like AddRange(), which are necessary to implement patterns to repopulate a collections (see https://docs.microsoft.com/en-us/visualstudio/code-quality/ca2227?view=vs-2019 and IDL4CSP-1).

    As discussed in the IDL WG at the September meeting, it would be desirable to map Sequences to an Omg.Types.ISequence<T> interface that extends System.Collections.Generic.IList<T> and adds all the properties and methods in the System.Collections.Generlic.List<T> class.

  • Reported: IDL4-CSHARP 1.0a1 — Wed, 30 Sep 2020 09:37 GMT
  • Disposition: Resolved — IDL4-CSHARP 1.0
  • Disposition Summary:

    Define a more complete interface for Sequence Types

    This resolution introduces Omg.Types.ISequence, an interface to represent sequence types that is more complete than the generic System.Collections.Generic.IList<T>.

    Omg.Types.ISequence provides the same methods and constructors as the standard C# System.Collections.Generic.List<T>.

    The resolution of this issue requires applying the resolution of IDL4CSP-1 first.

  • Updated: Mon, 29 Mar 2021 12:23 GMT

Do the copy and all values constructors make deep copies or shallow copies?

  • Key: IDL4CSP-5
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Fernando Garcia-Aranda)
  • Summary:

    The current version of the specification does not specify whether copy constructors and all value constructors do deep copies or shallow copies. The specification should indicate what's expected from an implementation to avoid problems. such as those highlighted here.

  • Reported: IDL4-CSHARP 1.0a1 — Tue, 15 Sep 2020 18:00 GMT
  • Disposition: Resolved — IDL4-CSHARP 1.0
  • Disposition Summary:

    Introduce Clarifications about Copying Behavior in Constructors and Setters

    This resolution clarifies the copy behavior (whether shallow or deep copies must be performed) in constructors and setters. Also, it clarifies how the @external annotations affects such behavior.

    This resolution shall be applied after applying the changes introduced in the resolution of IDL4CSP-1.

  • Updated: Mon, 29 Mar 2021 12:23 GMT

Typos and Inconsistencies

  • Key: IDL4CSP-4
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Fernando Garcia-Aranda)
  • Summary:

    In Section 7.2.3.1 "Alternative Mapping", there's a double public in the second paragraph that should be removed: "... the public public partial class shall..."

    Table 7.1 lists the use of the dynamic type, which was part of the original draft but is no longer part of the IDL to C# mapping. Therefore, the row referencing dynamic should be removed.

    The mapping of constants in Section 8.1.2 constants_container Parameter does not match to the mappings defined in Section 7.2.3

  • Reported: IDL4-CSHARP 1.0a1 — Tue, 15 Sep 2020 12:49 GMT
  • Disposition: Resolved — IDL4-CSHARP 1.0
  • Disposition Summary:

    Fix typos and inconsistencies

    This resolution addresses all reported typos and inconsistencies.

  • Updated: Mon, 29 Mar 2021 12:23 GMT

Resolution for name clashes with the Discriminator property name is invalid

  • Key: IDL4CSP-6
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Fernando Garcia-Aranda)
  • Summary:

    The proposed conflict resolution rules for union members called Discriminator, which prepend an '@' in front of union member named Discriminator, are invalid. The '@' can only be applied to names that conflict with C# keywords (see https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/inside-a-program/identifier-names).

  • Reported: IDL4-CSHARP 1.0a1 — Tue, 15 Sep 2020 19:10 GMT
  • Disposition: Resolved — IDL4-CSHARP 1.0
  • Disposition Summary:

    Add conflict resolution rules for conflicts with identifiers that are not C# keywords

    Currently the specification only defines conflict resolution rules for names that conflict with C# keywords. This resolution introduces a rule to resolve conflicts with names that are not C# keywords.

    The resolution also provides a valid solution to resolve name clashes with the property representing the union discriminator that is consistent with the IDL4 to Java Language Mapping.

  • Updated: Mon, 29 Mar 2021 12:23 GMT

Interface argument modifiers

  • Key: IDL4CSP-7
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Fernando Garcia-Aranda)
  • Summary:

    Input interface arguments shouldn't have the "in" modifier.

  • Reported: IDL4-CSHARP 1.0a1 — Tue, 15 Sep 2020 19:18 GMT
  • Disposition: Resolved — IDL4-CSHARP 1.0
  • Disposition Summary:

    Fix mapping of in arguments in interface methods

    As reported in the issue, the mapping of in arguments in interface methods is incorrect. In this resolution, we change the mapping of in arguments so they're mapped to parameters without a modifier.

  • Updated: Mon, 29 Mar 2021 12:23 GMT

Missing option in @csharp_mapping annotation to document mapping to standalone constant classes

  • Key: IDL4CSP-14
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Fernando Garcia-Aranda)
  • Summary:

    The @csharp_mapping annotation introduced in Clause 8.1 provides an argument to select the alternative constants mapping and provide a name for the class that scopes a group of contants. However, there current syntax does not allow indicating that mapped constants shall be mapped as standalone classes, which is the other mapping option. Perhaps, we could give a name for the mapping that maps constants to standalone classes, and map that to setting constants_container to an empty string.

    As a side issue with constants, in both mappings the classes that contain the constants are not static. This may confusing as you could create instances of a class that only has constants, which are static. Perhaps, the "Standalone Constants Mapping" should create classes that are "public static" (which are also sealed), and the alternative mapping should create "public static partial" classes.

  • Reported: IDL4-CSHARP 1.0a1 — Fri, 30 Oct 2020 17:01 GMT
  • Disposition: Resolved — IDL4-CSHARP 1.0
  • Disposition Summary:

    Extend constants_container parameter of @csharp_mapping to specify how to map to standalone classes and convert classes containng constants to static classes

    This resolution provides names for the two mapping options for constants and specifies how to select each of them using the @csharp_mapping annotation. It also converts the classes that wrap constants in both mapping options into "static classes".

    The resolution to this issue must be applied after the resolution of IDL4CSP-4.

  • Updated: Mon, 29 Mar 2021 12:23 GMT

Use of Omg.Types

  • Key: IDL43-39
  • Status: open  
  • Source: Objective Interface Systems ( Mr. Chuck Abbott)
  • Summary:

    The use of the Omg.Types name should be changed to OMG.Types.

  • Reported: IDL4-CSHARP 1.1b1 — Fri, 26 Mar 2021 15:40 GMT
  • Updated: Fri, 26 Mar 2021 15:40 GMT

Partial classes cannot span assemblies

  • Status: open  
  • Source: Objective Interface Systems ( Mr. Chuck Abbott)
  • Summary:

    Every scope containing a constant declaration shall contain a public static partial class.

    The "public static partial class" is inconsistent with the examples in 7.2.3.1 above.

    The use of "partial" is suspect and cannot span assemblies. It may be useful for forward interface declarations though whose definition appears in another IDL file.

  • Reported: IDL4-CSHARP 1.1b1 — Wed, 24 Mar 2021 13:22 GMT
  • Updated: Wed, 24 Mar 2021 13:47 GMT