IDL4 to C# Language Mapping Avatar
  1. OMG Specification

IDL4 to C# Language Mapping — Closed Issues

  • Acronym: IDL4-CSHARP
  • Issues Count: 9
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Descriptions

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