ETSI's Bug Tracker - TTCN-3 Change Requests
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0008108 | TTCN-3 Change Requests | Clarification | public | 16-08-2022 07:43 | 04-01-2023 11:12

Reporter | Matthias Simon |
Assigned To | Jens Grabowski |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Clause Reference(s) | 5.2.2 Uniqueness of identifiers
For STF discussion |
Source (company - Author) | Nokia -- Matthias Simon

Summary | 0008108: Uniqueness of identifiers for fields and enumerations

Description

The core language standard states that identifiers of scope units shall be unique:
> TTCN-3 requires uniqueness of identifiers, i.e. all identifiers in the same scope hierarchy shall be distinctive.
> This means that a declaration in a lower level of scope shall not re-use the same identifier as a declaration in
> a higher level of scope in the same branch of the scope hierarchy.
However it is not clear if this requirement includes field identifiers of records or enumeration labels or not.
I'd argue they are not included. Hence I propose to add some clarifying examples:
EXAMPLE 3: Explicit scopes
// The following IS allowed as the custom type definition provide an explicit scope for fields and enumeration labels
module A {
type record B {
integer A,
integer B
}
type enumerated C { A, B }
}

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR8108.docx (80,337) 09-11-2022 11:44 http://oldforge.etsi.org/mantis/file_download.php?file_id=4074&type=bug CR8108-r1.docx (80,749) 11-11-2022 10:53 http://oldforge.etsi.org/mantis/file_download.php?file_id=4079&type=bug

Issue History
Date Modified | Username | Field | Change
16-08-2022 07:43 | Matthias Simon | New Issue |
16-08-2022 09:03 | Jens Grabowski | Note Added: 0016212 |
16-08-2022 09:04 | Jens Grabowski | Assigned To | => Jens Grabowski
16-08-2022 09:04 | Jens Grabowski | Status | new => assigned
08-11-2022 11:59 | Jens Grabowski | Assigned To | Jens Grabowski => Axel Rennoch
09-11-2022 11:44 | Axel Rennoch | File Added: CR8108.docx |
09-11-2022 11:45 | Axel Rennoch | Note Added: 0016274 |
09-11-2022 11:45 | Axel Rennoch | Assigned To | Axel Rennoch => Matthias Simon
09-11-2022 11:45 | Axel Rennoch | Status | assigned => confirmed
09-11-2022 15:46 | Matthias Simon | Note Added: 0016281 |
09-11-2022 15:51 | Matthias Simon | Note Edited: 0016281 | bug_revision_view_page.php?bugnote_id=16281#r599
09-11-2022 16:25 | Matthias Simon | Note Added: 0016282 |
10-11-2022 21:05 | Matthias Simon | Assigned To | Matthias Simon => Axel Rennoch
11-11-2022 10:53 | Axel Rennoch | File Added: CR8108-r1.docx |
11-11-2022 10:54 | Axel Rennoch | Assigned To | Axel Rennoch => Matthias Simon
11-11-2022 10:54 | Axel Rennoch | Status | confirmed => assigned
11-11-2022 10:55 | Axel Rennoch | Note Added: 0016308 |
06-12-2022 10:08 | Matthias Simon | Assigned To | Matthias Simon => Axel Rennoch
06-12-2022 13:12 | Jens Grabowski | Status | assigned => resolved
06-12-2022 13:12 | Jens Grabowski | Resolution | open => fixed
06-12-2022 13:12 | Jens Grabowski | Assigned To | Axel Rennoch => Jens Grabowski
04-01-2023 11:12 | Jens Grabowski | Note Added: 0016463 |
04-01-2023 11:12 | Jens Grabowski | Status | resolved => closed

Notes

(0016212)
Jens Grabowski
16-08-2022 09:03

TTF Discussion: Examples are correct and should be added.

(0016274)
Axel Rennoch
09-11-2022 11:45

Examples have been added. Please check to resolve the issue.

(0016281)
Matthias Simon
09-11-2022 15:46 (edited on: 09-11-2022 15:51)

Do you think we should find a different term for "explicit scopes"?
Because we don't use "explicit scope" anywhere else in the standard. Similarly, I would suggest to rename:
* "field labels" to "field identifiers"
* "enumeration labels" to "enumerated values"
I think a consistent use of terms is beneficial. How about:
EXAMPLE 4: User defined type scopes
module A {
type record B { // Identifiers for fields of structured types do not have to be globally unique identifiers
integer A, // no name clash with module identifier
integer B // no name clash with record identifier
}
type enumerated C { // Identifiers for enumerated do not have to be globally unique
// TODO: See follow up comment.
}
Further I think we have to discuss, if my proposed example for enumerated types is not correct.

(0016282)
Matthias Simon
09-11-2022 16:25

I believe my enumerated type example is not correct:
type enumerated C {
A, // name clash with module identifier
B, // name clash with identifier of previous record definition
C, // name clash with identifier of enumerated type
}
The enumerated values violate restriction [1]:
> # Chapter 5.2.2 "Uniqueness of identifiers":
> [1] enumerated values [...] within the same module [...] shall only be reused:
> [1a] for enumerated values within other enumerated types
> [1b] as identifiers for fields of structured types

(0016308)
Axel Rennoch
11-11-2022 10:55

Please check the modified solution following your notes.

(0016463)
Jens Grabowski
04-01-2023 11:12

Implemented as proposed in resolution.