Home » Eclipse Projects » Eclipse Titan » concatenating templates of list types
| concatenating templates of list types [message #1780794] |
Sat, 27 January 2018 14:31  |
|
ES 201 873-1 Section 15.11 states that templates of list types can be concatenated.
However, I'm having trouble doing this in TITAN.
Are there any known restrictions? I'm getting the following compiler error from TITAN 6.3.0, which seems to hint that the '&' operator expects values, not templates:
GSUP_Types.ttcn:221.9-18: In the left operand of operation `&':
GSUP_Types.ttcn:221.9-11: error: Reference to a value was expected instead of template parameter `ies'
GSUP_Types.ttcn:221.9-18: In the right operand of operation `&':
GSUP_Types.ttcn:221.16-17: In component #1:
GSUP_Types.ttcn:221.16-17: error: Reference to a value was expected instead of template parameter `ie'
I couldn't find any mention in the TITAN reference guide / programmer manual on any such restriction. Thanks!
|
|
|
| Re: concatenating templates of list types [message #1780845 is a reply to message #1780794] |
Mon, 29 January 2018 08:13  |
|
Hi Harald,
parameters passed to a template are considered value parameters unless
declared otherwise.
Hence
template GSUP_PDU ts_GSUP_CL_REQ(hexstring imsi, GSUP_CancelType ctype) :=
ts_GSUP(OSMO_GSUP_MSGT_LOCATION_CANCEL_REQUEST, { ts_GSUP_IE_IMSI(imsi), ts_GSUP_IE_CancelType(ctype) });
template GSUP_PDU ts_GSUP(GSUP_MessageType msgt, GSUP_IEs ies := {}) := {
msg_type := msgt,
ies := ies
}
template GSUP_IE ts_GSUP_IE_CancelType(GSUP_CancelType ctype) := {
tag := OSMO_GSUP_CANCEL_TYPE_IE,
len := 0, /* overwritten */
val := {
cancel_type := ctype
}
}
template GSUP_IE ts_GSUP_IE_IMSI(hexstring imsi) := {
tag := OSMO_GSUP_IMSI_IE,
len := 0, /* overwritten */
val := {
imsi := imsi
}
}
will not work , as Titan needs to convert ts_GSUP_IE_CancelType, ts_GSUP_IE_IMSI to values,
but
template GSUP_PDU ts_GSUP_CL_REQ(hexstring imsi, GSUP_CancelType ctype) :=
ts_GSUP(OSMO_GSUP_MSGT_LOCATION_CANCEL_REQUEST, { ts_GSUP_IE_IMSI(imsi), ts_GSUP_IE_CancelType(ctype) });
template GSUP_PDU ts_GSUP(GSUP_MessageType msgt, template GSUP_IEs ies := {}) := {
msg_type := msgt,
ies := ies
}
template GSUP_IE ts_GSUP_IE_CancelType(GSUP_CancelType ctype) := {
tag := OSMO_GSUP_CANCEL_TYPE_IE,
len := 0, /* overwritten */
val := {
cancel_type := ctype
}
}
template GSUP_IE ts_GSUP_IE_IMSI(hexstring imsi) := {
tag := OSMO_GSUP_IMSI_IE,
len := 0, /* overwritten */
val := {
imsi := imsi
}
}
will. Note that I have changed the type of parameter GSUP_IEs ies := {} in
ts_GSUP to template
I hope this clarifies it.
Best regards
Elemer
|
|
|
| Re: concatenating templates of list types [message #1781022 is a reply to message #1780845] |
Wed, 31 January 2018 16:04 |
|
Thanks. It's actually easy enough I could have figured it out myself :/
I always try to use template arguments only in receive templates, but use value arguments in send templates. But that general rule of thumb of course doesn't work here, and I understand *why* it behaves the way you described.
btw: What I find conceptually difficult to accept is that I can declare a template with (value) restriction, and hence the template can always only have a "fully qualified value", but then I still need to use valueof() that (value) template. But then, that's just how the language is specified, no use of me complaining about my personal usability concerns here ;)
|
|
|
| Re: concatenating templates of list types [message #1781070 is a reply to message #1781022] |
Thu, 01 February 2018 07:46 |
|
Hi Harald,
I see you point , of course the compiler could automatically invoke value conversion; however there's an approach I 'd recommend you:
The language itself was not meant for programmers but for protocol experts who don't necessarily have a strong background in programming; their primary focus is the node or
protocol under investigation. Hence the code, distributed in source, should be as straightforward, easily readable and unequivocal as possible. There's no room for obfuscation and each step
has to be marked clearly. Any unnecessary complication is just an unwanted irritation for the user.
In some points Titan even surpasses the standard in this respect : we prefer that everything happens aboveboard, in an explicit manner.
I myself prefer to think of TTCN-3 as a protocol analyzer/generator disguised in the form of a programming language. This is a good argument when trying to disarm those developers that question even the right to existence of the language, pointing out features that from their point of view appear to be missing.
Best regards
Elemer
|
|
|
Goto Forum:
Current Time: Tue Apr 23 11:41:50 GMT 2024
Powered by FUDForum. Page generated in 0.04059 seconds |
] 
Search
Help
Register
Login
Home
