DDS4CCM 1.0 FTF Avatar
  1. OMG Issue

DDS4CCM_ — Destination module for implied template interfaces

  • Key: DDS4CCM_-69
  • Legacy Issue Number: 14201
  • Status: closed  
  • Source: Vanderbilt University ( Mr. William Otte)
  • Summary:

    Suppose we have this:

    ========
    foo.idl:
    module Foo
    {
    interface Foo_Intf < typename T >
    {
    };
    };

    =========
    bar.idl:
    #include "foo.idl"
    module Bar
    {
    porttype Bar_Port <typename T>

    { uses Foo_Intf<T> foo_port; }

    ;
    };

    =========
    baz.idl:
    #include "bar.idl"
    module Baz
    {
    struct Baz_Struct
    {
    };
    };

    =========
    foobarbaz.idl:
    #include "baz.idl"
    module FooBarBaz
    {
    connector FooBarBaz_Connector

    { mirrorport Bar_Port < Baz::Baz_Struct > foobarbaz_port; }

    ;
    };

    =========

    In which module(s) are the implicit interfaces for Bar_Port and
    Foo_Intf (with respect to their parameterization with Baz_Struct)
    assumed to be declared?

  • Reported: DDS4CCM 1.0b1 — Sun, 23 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    To give names to the instantiated interfaces, the initial version of the specification
    was proposing a naming convention which was far from covering all the cases as
    shown by this issue. In addition, this strategy was not in line with the one
    selected by IDL to get rid of anonymous types resulting from instantiation of
    existing templates (such as sequences). IDL now requires an explicit instantiation
    with a name allocated by the developer.
    It has thus been decided to remove that naming convention and to rely on
    explicit instantiations.
    Ina addition, a typical use case for parametrized extended ports and connectors
    is as follows: a parametrized interface is used in a similarly parametrized port
    type, which itself is used in a similarly parametrized connector. Eventually, when
    instantiated, it is mandatory that the concrete interface in support of the extended
    port attached to a component be exactly the same type as the one if support to
    the corresponding mirror port of the connector (otherwise connections will not be
    feasible), when in fact two explicit interface instantiations would result in two
    different types (even if identical). Therefore it is mandatory that the interface, the
    port type and the connector be in the same template scope, to allow a unique
    interface instantiation be shared by the instantiated port type and connector.
    This lead to proposing template support for the only grouping structure of IDL,
    namely the module. Adding template modules is on the one hand less intrusive in
    the existing IDL grammar and on the other hand far more versatile than the initial
    proposed support. As it is needed to support almost all the possible extended
    ports and connectors and enough for that purpose, it was decided to limit the
    template support to template modules.
    Consequently it was needed to recast almost entirely chapter 7, in order to
    present in one place the template support (while in the initial chapter
    organization, it was spread over the descriptions of each of the interaction
    constructs – port types, ports, connectors). The resulting outline is as follows:
    7 Generic Interaction Support
    7.1 Simple Generic Interaction Support
    7.2 Generic Interaction Support with Templates
    7.3 IDL3+ Grammar
    7.4 Programming Model for Connectors
    7.5 Connector Deployment and Configuration taking the opportunity of this recast, the whole grammar description has been
    rewritten in order to make it closer to the initial IDL grammar.

  • Updated: Sat, 7 Mar 2015 00:50 GMT