ETSI's Bug Tracker |
Anonymous | Login | Signup for local Mantis account | 30-04-2024 15:29 IST |
Main | My View | View Issues | Change Log | Roadmap | Monitor project |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||||||
0008194 | Part 01: TTCN-3 Core Language | New Feature | public | 20-01-2023 13:26 | 26-01-2024 16:32 | ||||||||
Reporter | Matthias Simon | ||||||||||||
Assigned To | Matthias Simon | ||||||||||||
Priority | normal | Severity | minor | Reproducibility | have not tried | ||||||||
Status | assigned | Resolution | open | ||||||||||
Platform | OS | OS Version | |||||||||||
Product Version | |||||||||||||
Target Version | Fixed in Version | ||||||||||||
Summary | 0008194: Optional Names for Formal Parameters | ||||||||||||
Description | The current TTCN-3 specification requires formal parameters to have names, even when they are not used in the code, which can create confusion when using assignment notation and make the code harder to read. To solve this problem, I propose that we allow developers to omit the names of formal parameters. This change would reduce noise in the code, as unnecessary parameter names would no longer be required. It would be especially useful when specifying built-in functions and interfaces, as it would make the code more readable and easier to understand. | ||||||||||||
Tags | No tags attached. | ||||||||||||
Clause Reference(s) | 5.4.1 -- Formal Parameters | ||||||||||||
Source (company - Author) | Nokia - Matthias Simon | ||||||||||||
Attached Files | |||||||||||||
Notes | |
(0016518) Jens Grabowski (manager) 05-09-2023 10:13 |
TTF discussion: Benefit is not obvious. Examples are needed. |
(0016576) Jens Grabowski (manager) 10-11-2023 10:19 |
TTF discussion: Matthias will provide examples and proposal. |
(0016583) Matthias Simon (developer) 21-12-2023 09:01 |
It's helpful when parameters are not used, but mandatory. This happens for behaviour-types, abstract classes, traits and external functions: type function HandlerFunc(in Request) return Response; external function registerHandler(in HandlerFunc); // emptyHandler always returns an empty Response value function emptyHandler(in Request) return Response { return Response:{} } |
(0016617) Olivier Genoud (administrator) 26-01-2024 16:32 |
According to the example it seems, that purpose of the CR is for use of a function as parameter or variable which is not part of the core language => The CR may enable a notation which only makes sense in the context of an extension package. On the other hand, the mentioned confusion can also be avoided by appropriate naming (e.g. "p_Dummy" or "p_NotUsed"). i.e. the issue can be solved by project-specific naming conventions rather than changing the core language. |
Issue History | |||
Date Modified | Username | Field | Change |
20-01-2023 13:26 | Matthias Simon | New Issue | |
05-09-2023 10:13 | Jens Grabowski | Note Added: 0016518 | |
05-09-2023 10:13 | Jens Grabowski | Assigned To | => Matthias Simon |
05-09-2023 10:13 | Jens Grabowski | Status | new => assigned |
10-11-2023 10:19 | Jens Grabowski | Note Added: 0016576 | |
21-12-2023 09:01 | Matthias Simon | Note Added: 0016583 | |
26-01-2024 16:32 | Olivier Genoud | Note Added: 0016617 |
MantisBT 1.2.14 [^] Copyright © 2000 - 2024 MantisBT Team |