Notes |
|
|
global address type has effect on port type defintions in the same module only without local address type reference. |
|
|
|
Attached a rephrasing proposal to the CR 2105 proposal to reflect the recommended use. |
|
|
|
The following sentence does not make sense in the context of the new port-bound address feature:
"Explicit SUT addresses shall only be generated inside a TTCN‑3 module if the type is defined inside the module (globally or within port type definitions). If the type is not defined inside the module, explicit SUT addresses shall only be passed in as parameters or be received in message fields or as parameters of remote procedure calls."
It should (at least) be changed to:
"Explicit SUT addresses for a globally defined address type shall only be generated inside a TTCN‑3 module if the type is defined inside the module itself. If the type is not defined inside the module, explicit SUT addresses for a global address type shall only be passed in as parameters or be received in message fields or as parameters of remote procedure calls."
In my opinion, the whole sentence could be removed as it is an unnecessary restriction. Why should not module B which imports module A, then use A.address like any other type if it uses a port type defined in module A which has no address-type bound?
==============================================================================
The example which receives addresses should instead be changed to use the sender/from clause(s) because there you need the agreement between the address variables and the address type. |
|
|
|
added my changes in CR-2105 + CR-5588-Jacob.doc |
|
|
|
Looks good to me. Assigned to Ina. |
|
|
|
The agreed syntax from CR2105 is implemented in part 1:
type port PortTypeIdentifier message "{"
[ address Type “;†]
[ map param "(" { FormalValuePar [","] }+ ")" ]
[ unmap param "(" { FormalValuePar [","] }+ ")" ]
{ ( in | out | inout ) { MessageType [ "," ] }+ ";" }
"}"
etc. |
|
|
|
see uploaded BNF for defining address types in ports |
|