Status: open Implementation work Blocked
Source: Object Computing, Inc. - OCI ( Adam Mitz)
Section 184.108.40.206.2 describes the algorithm for computing type identifiers for strongly connected components. Step 4b says
If the Strongly Connected Component (SCC) has multiple types, then sort them using the lexicographic order of their fully qualified type name. Let SCCIndex(U) be the sort index of each type U belonging to the SCC starting with index 1 for the first type. For anonymous types concatenate the fully qualified name of the containing type with the member name using “.” as the separator, for example “MyModule::MyStruct.myMember”.
This does not cover all possibilities for anonymous types. To illustrate, the following IDL with recursive types uses an anonymous type in a typedef:
The algorithm requires a name for sequence<@external TreeNode>. In general, the rule for naming anonymous types in step 4b must be expanded to include anywhere an anonymous type may appear including structs, unions, typedefs, and other anonymous types.
An additional, related, problem is that given the definition of Plain...
220.127.116.11 “Plain types only have a TypeIdentifier. Non-plain types have both a TypeIdentifier and a TypeObject.”
the children field of TreeNode of the SCC example in 18.104.22.168 is a Plain Collection and has no TypeObject
Step 4(b)ii of the algorithm in 22.214.171.124.2 requires that all of the types in an SCC have a TypeObject 4(b)ii.
Possible Solutions and Notes:
The algorithm implies that all of the types involved in a Strongly Connected Component have a type identifier of TI_STRONGLY_CONNECTED_COMPONENT. The precludes the use of the Plain Collections in Strongly Connected Components. Thus, if the algorithm of 126.96.36.199.2 is not revised, then the definition of Plain Collections needs to be revised to exclude those involved in a Strongly-Connected Component.
Reported: DDS-XTypes 1.3 — Wed, 2 Sep 2020 16:25 GMT
Updated: Wed, 21 Sep 2022 18:45 GMT