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

ID | Project | Category | View Status | Date Submitted | Last Update
0006774 | Part 01: TTCN-3 Core Language | New Feature | public | 16-06-2014 10:02 | 23-09-2015 08:56

Reporter | Wolfgang Seka |
Assigned To | Jens Grabowski |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | won't fix |
Platform |  | OS |  | OS Version |
Product Version | v4.5.1 (published 2013-04) |
Target Version | v4.8.1 (published 2016-07) | Fixed in Version |  |
Clause Reference(s) | 16.2
Source (company - Author) | MCC160 - Wolfgang

Summary | 0006774: Return values for altsteps

Description

With "-> value" acc. to cl. 22.2.2 in a receive statement a value can be stored in a variable. This concept shall be enhanced for altsteps as well:
It shall be possible to declare a return value for an altstep which can be assigned to a variable with "-> value".
NOTE: as for receive statements there is no need to assign the receive value to a variable directly with the ":=" operator (at least from MCC160's point of view).

Steps To Reproduce |

Additional Information

Use case:
Especially with SIP we cannot fully check the correctness of a message by means of receive templates but need to do further checking after we have received a message; furthermore we may need to respond to requests immediately and but we also may need to refer to the content of messages later on.
Now - we have scenarios where some requests need to be received in any order or some of them are even optional.
=> it is useful to have a set of altsteps to receive a single Message, check it and respond to it.
So - what I would do when possible is e.g.
alt {
[] a_ReceiveCheckRespondToMessage1(...) -> value v_Message1 {...}
[] a_ReceiveCheckRespondToMessage2(...) -> value v_Message2 {...}
[] a_ReceiveCheckRespondToMessage3(...) -> value v_Message3 {...}
...
[] t_Timer.timeout {...}
}
=> improve readability, avoidance of "out" paramters

Tags | No tags attached.
Relationships |
Attached Files | Discussion-CR6774.pptx (51,721) 06-08-2015 11:18 http://oldforge.etsi.org/mantis/file_download.php?file_id=3242&type=bug

Issue History
Date Modified | Username | Field | Change
16-06-2014 10:02 | Wolfgang Seka | New Issue |
17-06-2014 11:57 | Gyorgy Rethy | Assigned To | => Jens Grabowski
17-06-2014 11:57 | Gyorgy Rethy | Status | new => assigned
17-06-2014 16:00 | Gyorgy Rethy | Project | TTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-06-2014 16:01 | Gyorgy Rethy | Product Version | => v4.5.1 (published 2013-04)
17-06-2014 16:01 | Gyorgy Rethy | Target Version | => v4.7.1 (published 2015-06)
06-11-2014 09:17 | Gyorgy Rethy | Target Version | v4.7.1 (published 2015-06) => v4.8.1 (published 2016-07)
06-08-2015 11:18 | Jens Grabowski | File Added: Discussion-CR6774.pptx |
06-08-2015 11:19 | Jens Grabowski | Note Added: 0013110 |
06-08-2015 14:13 | Gyorgy Rethy | Note Added: 0013117 |
23-09-2015 08:54 | Jens Grabowski | Note Added: 0013246 |
23-09-2015 08:56 | Jens Grabowski | Status | assigned => closed
23-09-2015 08:56 | Jens Grabowski | Resolution | open => won't fix

Notes

(0013110)
Jens Grabowski
06-08-2015 11:19

Slideset for STF internal discussion uploaded.

(0013117)
Gyorgy Rethy
06-08-2015 14:13

STF discussion 06-08-2015: After discussiong the analysis the STF view is that the feature would complicate the language with a lots of special rules. The same readibility can be achieved by using out parameters in altsteps and/or using components variables and commenting the code.

(0013246)
Jens Grabowski
23-09-2015 08:54

After a short Email discussion with the reporter, the CR will not be implemented. The gain by the feature compared with the complication of the language with lots of special rules is too low.