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

ID | Project | Category | View Status | Date Submitted | Last Update
0005393 | Part 01: TTCN-3 Core Language | Editorial | public | 13-10-2009 16:01 | 08-12-2009 18:28

Reporter | Philip Makedonski |
Assigned To | Ina Schieferdecker |
Priority | normal | Severity | major | Reproducibility | always
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version | v4.1.1 (published 2009-06) |
Target Version | v4.2.1 (published 2010-07) | Fixed in Version | v4.2.1 (published 2010-07) |
Clause Reference(s) | A.1.6.1.0 General, Multiple
Source (company - Author) | University of GÃ¶ttingen

Summary | 0005393: Follow-up: 0005291: BNF - friend definitions should have no visibility

Description

Since I cannot reopen a closed issue, this issue is related to issue 0005291 and the visibility problems with friend modules, import statements and groups:
(original text by Gyorgy Rethy, my comments in the bottom)
The current BNF allows visibility for friend definitions, while the textual part (clause 8.2.4) does not:
8.2.4 Definition of friend modules
Syntactical Structure
friend module ModuleIdentifier { "," ModuleIdentifier } ";"
On the other hand side clause 8.2.5 says "(top level definitions) They are by default public except for imported definitions which are by default private."
Thus friend definitions, according to $8.2.5, should be public. But, in fact, they have meaning for the given module only and they are not importable; hence, as a matter of fact, they are always private.
-------------------
Two solutions are possible:
1) (preferred) Make the private keyword mandatory in $8.2.4:
Syntactical Structure
private friend module ModuleIdentifier { "," ModuleIdentifier } ";"
2) Modify the text in $8.2.5:
"They are by default public except for imported definitions and friend definitions which are by default private.
...
The visibility of imported definitions and friend definitions are by default always private. All other module definitions are by default public."
-------------
Solution 1), though would introduce a mandatory syntax, which is optional for other definitions, is the preferred one, as solution 2) would introduce a new exception; users looking at a friend definitions without a visibility keyword could think that friend lists are also imported.
======================================================
(commment by Ina Schieferdecker)
In analogy to groups, which can be public only, a solution can be:
[ private ] friend module ModuleIdentifier { "," ModuleIdentifier } ";"
Adding a restriction:
In addition to the general static rules of TTCN 3 given in clause 5, the following restrictions apply:
a) Only private visibility can be defined for friend definitions as they are always private.
And extending 8.2.5 accordingly:
Top-level module definitions and import statements have a visibility, which can be explicitly set. They are by default public except for imported and friend definitions. Import definitions are by default private. Friend definitions are private only. Group definitions are public only.
======================================================
(my comments)
...and confusion ensues...
Why does the description as "by default" keep being brought up in the context of import and friend definitions? The standard currently says "private only" and "always private" for imports and "public only" and "always public" for groups. What would "private by default" suggest in this context? That they can eventually be made friend or public?!
I'd keep the wording consistent to avoid further confusion - either "public only" or "always public" in all instances, but adding "by default" to the mix is going to far if by that one of the former expressions is meant.. that is if I am not missing some part of the discussion..
So to spell it out: Multiple adaptations will be necessary in text, to cover all the instances, but briefly:
"Import and friend definitions cannot be imported and thus can be private only, group definitions can be public only. All other importable definitions are public by default."
This would reflect the default visibility settings (in the case that the syntax is not changed so as to require that imports and friends are explicitly declared as private, although it will be necessary sooner or later).
In any case, one proposal for the syntax will therefore be:
{
(
( [ "private" ]
( ImportDef |
FriendDef
)
)
|
( [ "public" ]
GroupDef
)
|
( [ Visibility ] (
TypeDef |
ConstDef |
TemplateDef |
ModuleParDef |
FunctionDef |
SignatureDef |
TestcaseDef |
AltstepDef |
ExtFunctionDef
)
)
[ WithStatement ]
[ ";" ]
}+
, where the optionality of the "private" and "public" visibility modifiers may be dropped.
Changes have to be propagated accordingly to all the relevant sections.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files |

Issue History
Date Modified | Username | Field | Change
13-10-2009 16:01 | Philip Makedonski | New Issue |
13-10-2009 16:01 | Philip Makedonski | Status | new => assigned
13-10-2009 16:01 | Philip Makedonski | Assigned To | => Ina Schieferdecker
13-10-2009 16:01 | Philip Makedonski | Clause Reference(s) | => A.1.6.1.0 General, Multiple
13-10-2009 16:01 | Philip Makedonski | Source (company - Author) | => University of GÃ¶ttingen
07-12-2009 14:04 | Ina Schieferdecker | Target Version | => Edition 4.2.1 (not yet published)
08-12-2009 18:04 | Ina Schieferdecker | Note Added: 0009107 |
08-12-2009 18:12 | Ina Schieferdecker | Note Added: 0009108 |
08-12-2009 18:28 | Ina Schieferdecker | Status | assigned => resolved
08-12-2009 18:28 | Ina Schieferdecker | Resolution | open => fixed
08-12-2009 18:28 | Ina Schieferdecker | Fixed in Version | => Edition 4.2.1 (not yet published)
08-12-2009 18:28 | Ina Schieferdecker | Status | resolved => closed

Notes

(0009107)
Ina Schieferdecker
08-12-2009 18:04

In version 4.1.3, the import of imports has been introduced. Therefore it is required that import statements can be made visible - in order to enable their imports. They are private by default, which means that whenever no visibility is given the import statement is a private one. By giving a visibility explicitly, the visibility of imports can be overwritten.

(0009108)
Ina Schieferdecker
08-12-2009 18:12

It was agreed to make the various cases for visibility explicit in the BNF: ModuleDefinition ::= ( ([Visibility] ( TypeDef | ConstDef | TemplateDef | ModuleParDef | FunctionDef | SignatureDef | TestcaseDef | AltstepDef | ImportDef | ExtFunctionDef | ExtConstDef ) ) | (["public"] GroupDef ) | (["private"] FriendModuleDef ) ) [WithStatement]