ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0008098 | Part 01: TTCN-3 Core Language | Technical | public | 09-08-2022 13:27 | 26-01-2024 16:30

Reporter | Matthias Simon |
Assigned To | Jens Grabowski |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | won't fix |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version |  | Fixed in Version |  |
Clause Reference(s) | 8.2.3.1 -- General format of import
Source (company - Author) | Nokia - Matthias Simon

Summary | 0008098: Mandatory module prefix for imported module defintitions

Description

SUMMARY
Make the module prefix mandatory for imported module definitions, to improve TTCN-3 readability.
DESCRIPTION
Module definitions usually have some kind of module-prefix or suffix in their name to communicate their ownership/domain (similar to C).
Here's one example from an ETSI SIP module:
module LibSip_Interface {
type record Address4SIP ...
signature s_SIP_conversation ...
type port SipPort ...
type port OperatorPort ...
There are some issues which make this module harder to use and harder to comprehend:
* Names are difficult to remember, because of inconsistent naming schemes.
* Cumbersome and long disambiguation (`LibSip_Interface.s_SIP_conversation`).
* Missing/optional module names make it difficult to find the owning module of a definition (e.g. `OperatorPort`).
Looking at languages like Go or C++, there's a better way to name things: Encourage (or enforce) developers to drop the custom prefixes/suffixes and consistently use the full qualified name of imported module definitions:
module SIP {
type record Address ...
signature s_conversation ...
type port Port ...
type port OperatorPort ...
The usage of module definitions would be easier to understand: `SIP.s_conversation` vs. `LibSip_Interface.s_SIP_conversation`, `SIP.OperatorPort` vs `OperatorPort`.
PROPOSAL
Make the module prefix mandatory for referencing imported module definitions.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files |

Issue History
Date Modified | Username | Field | Change
09-08-2022 13:27 | Matthias Simon | New Issue |
16-08-2022 13:15 | Jens Grabowski | Note Added: 0016222 |
16-08-2022 13:15 | Jens Grabowski | Project | TTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2022 08:14 | Jens Grabowski | Assigned To | => Jens Grabowski
17-08-2022 08:14 | Jens Grabowski | Status | new => assigned
17-08-2022 08:14 | Jens Grabowski | Status | assigned => closed
17-08-2022 08:14 | Jens Grabowski | Resolution | open => won't fix
26-01-2024 16:30 | Olivier Genoud | Note Added: 0016613 |

Notes

(0016222)
Jens Grabowski
16-08-2022 13:15

TTF discussion: Not backwards compatible.

(0016613)
Olivier Genoud
26-01-2024 16:30

The proposal is not backward compatible and would cause us(TF160) to change everything (all function calls would need a module prefix)! In general naming conventions shall be project-specific with project specific tools checking them.