| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] |
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0008222 | TTCN-3 Change Requests | Clarification | public | 15-03-2024 08:34 | 15-03-2024 08:34 |
|
| Reporter | Martin Hauch | |
| Assigned To | | |
| Priority | normal | Severity | feature | Reproducibility | have not tried |
| Status | new | Resolution | open | |
| Platform | | OS | | OS Version | |
|
| Summary | 0008222: Clarification for renaming module |
| Description | It is possible to import multiple times from one module. What is allowed for the renaming?
1. Always the same renamed-name
2. diffent names are allowed for each import-statement
import from VerylongModuleNameB -> ShortRule1 { type MytypeA} with {encode "Rule1"};
import from VerylongModuleNameB -> ShortRule2 { type MytypeB} with {encode "Rule2"};
If 'VerylongModuleNameB' should further not be used to avoid type-clash for the type, VerylongModuleNameB could also not used for the second import?
I.e.
import from VerylongModuleNameB -> ShortRule1 { type MytypeA} with {encode "Rule1"};
import from ShortRule1 -> ShortRule2 { type MytypeB} with {encode "Rule2"};
should be used, but this means that ShortRule1 is also not usable to identify a type. In case of the renaming semantic should the original module-name be usable to define a new module-definition, or should the name be usable for field- or enumeration-values in type definitions?
In my opinion the semantic of an alias-name would be easier to understand. This would allow multiple aliases for a module-name and the module-name itself is still valid to identify an object uniquely. The usage of the alias-names should be handled in the same manner as the module-name.
|
| Tags | No tags attached. |
|
| Clause Reference(s) | TTCN-3 core language, chapter 8.2.3.1, EXAMPLE 4 |
| For STF discussion | |
| Source (company - Author) | Devoteam GmbH, Martin Hauch |
|
| Attached Files | |
|
Relationships 
Relationships 