-
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 >
{
};
};=========
{ uses Foo_Intf<T> foo_port; }
bar.idl:
#include "foo.idl"
module Bar
{
porttype Bar_Port <typename T>
;
};=========
baz.idl:
#include "bar.idl"
module Baz
{
struct Baz_Struct
{
};
};=========
{ mirrorport Bar_Port < Baz::Baz_Struct > foobarbaz_port; }
foobarbaz.idl:
#include "baz.idl"
module FooBarBaz
{
connector FooBarBaz_Connector
;
};=========
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
DDS4CCM_ — Destination module for implied template interfaces
- Key: DDS4CCM_-69
- OMG Task Force: DDS for CCM FTF 2