ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0006801 | Ext Pack: Object-oriented features (ES 203 790) | [All Projects] General | public | 09-10-2014 18:49 | 16-04-2018 11:56

Reporter | Gyorgy Rethy |
Assigned To | KristÃ³f Szabados |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | reopened |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version |  | Fixed in Version |  |

Summary | 0006801: Visibility of component definitions

Description

When defining libaries, it is often the case that some data shall not be manipulated by the users of the library directly; e.g. the internal database of a test framework, storing entity states, simulated entity-related data, temporary data like session ids etc. These are typically defined as component variables.
This is because the type and structure of framework-internal data may (in fact WILL) change over time, as the framework is developed further. But if the user access framework-internal data directly, these changes causes the user code be broken.
TTCN-3 doesn't have the means to disable direct access to component definitions. Please note, that at least the "top level" component types definitions of the framework shall be public, as the users shall be able to extend them.
The solution of the problem is to introduce visibily within components for component definitions as well:
In component member definitions they mean the following:
• The public modifier means that any function/testcase/altstep running on that component instance can access the member definition directly.
• The private modifier means that only those functions/testcases/altsteps can access the definition which refer to the component type in its runs on clause directly. If they run on a component type extending the one containing the definition, it will not be directly visible.
The friend modifier is not available within component types.
In this way framework-internal data is defined within private component types as private definitions. For data manipulation set and get functions are defined within the same module, with public visibility. These can be used by the users. Also, public component type(s), extending the private one is defined that other library modules or the users can use directly or extend further.
See attached code example.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.

Relationships

related to | 0007679 | closed | Jens Grabowski | Class Concept to be added
related to | 0007693 | closed | KristÃ³f Szabados | component members with visibility and functions inside the components

Attached Files

public_private_componentdef.ttcn (1,829) 09-10-2014 19:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=3138&type=bug
Component Field Visibility.pptx (56,670) 13-10-2015 10:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=3298&type=bug
CR6801_resolution_v1.docx (310,869) 15-10-2015 11:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=3312&type=bug
CR6801_resolution_v1_CommentsJG.docx (259,935) 16-10-2015 09:14
http://oldforge.etsi.org/mantis/file_download.php?file_id=3328&type=bug
CR6801_resolution_v2.docx (321,149) 16-10-2015 10:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=3329&type=bug
CR6801_resolution_v3.docx (321,797) 02-11-2015 13:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=3334&type=bug
CR6801_resolution_v4.docx (528,538) 02-11-2015 14:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=3337&type=bug
CR6801_resolution_v5.docx (262,590) 22-07-2016 13:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=3433&type=bug

Issue History
Date Modified | Username | Field | Change
09-10-2014 18:49 | Gyorgy Rethy | New Issue |
09-10-2014 18:50 | Gyorgy Rethy | File Added: public_private_moduledef.ttcn |
09-10-2014 18:50 | Gyorgy Rethy | File Deleted: public_private_moduledef.ttcn |
09-10-2014 18:52 | Gyorgy Rethy | File Added: public_private_componentdef.ttcn |
09-10-2014 18:59 | Gyorgy Rethy | File Deleted: public_private_componentdef.ttcn |
09-10-2014 19:00 | Gyorgy Rethy | File Added: public_private_componentdef.ttcn |
10-10-2014 09:46 | Jacob Wieland - Spirent | Note Added: 0012342 |
03-11-2014 09:34 | Gyorgy Rethy | Target Version | => v4.7.1 (published 2015-06)
06-11-2014 09:12 | Gyorgy Rethy | Target Version | v4.7.1 (published 2015-06) => v4.8.1 (published 2016-07)
21-11-2014 09:50 | Gyorgy Rethy | Product Version | => v4.7.1 (published 2015-06)
03-08-2015 15:25 | Gyorgy Rethy | Note Added: 0013042 |
03-08-2015 15:25 | Gyorgy Rethy | Assigned To | => Jens Grabowski
03-08-2015 15:25 | Gyorgy Rethy | Status | new => assigned
13-10-2015 07:29 | Jens Grabowski | Assigned To | Jens Grabowski => Jacob Wieland - Spirent
13-10-2015 10:34 | Jacob Wieland - Spirent | File Added: Component Field Visibility.pptx |
13-10-2015 10:35 | Jacob Wieland - Spirent | Note Added: 0013363 |
14-10-2015 15:30 | Gyorgy Rethy | Note Added: 0013387 |
15-10-2015 11:52 | Jacob Wieland - Spirent | File Added: CR6801_resolution_v1.docx |
15-10-2015 11:53 | Jacob Wieland - Spirent | Note Added: 0013394 |
15-10-2015 11:53 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Jens Grabowski
15-10-2015 11:53 | Jacob Wieland - Spirent | Status | assigned => confirmed
16-10-2015 09:14 | Jens Grabowski | Note Added: 0013423 |
16-10-2015 09:14 | Jens Grabowski | File Added: CR6801_resolution_v1_CommentsJG.docx |
16-10-2015 09:14 | Jens Grabowski | Assigned To | Jens Grabowski => Jacob Wieland - Spirent
16-10-2015 09:14 | Jens Grabowski | Status | confirmed => assigned
16-10-2015 10:26 | Jacob Wieland - Spirent | File Added: CR6801_resolution_v2.docx |
16-10-2015 10:27 | Jacob Wieland - Spirent | Note Added: 0013424 |
16-10-2015 10:27 | Jacob Wieland - Spirent | Note Added: 0013425 |
16-10-2015 10:27 | Jacob Wieland - Spirent | Status | assigned => confirmed
16-10-2015 10:27 | Jacob Wieland - Spirent | Status | confirmed => assigned
16-10-2015 10:28 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
16-10-2015 10:28 | Jacob Wieland - Spirent | Status | assigned => confirmed
02-11-2015 13:22 | Gyorgy Rethy | File Added: CR6801_resolution_v3.docx |
02-11-2015 13:28 | Gyorgy Rethy | Note Added: 0013436 |
02-11-2015 13:28 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent
02-11-2015 13:28 | Gyorgy Rethy | Status | confirmed => assigned
02-11-2015 14:31 | Jacob Wieland - Spirent | File Added: CR6801_resolution_v4.docx |
02-11-2015 14:33 | Jacob Wieland - Spirent | Note Added: 0013443 |
02-11-2015 14:33 | Jacob Wieland - Spirent | Status | assigned => resolved
02-11-2015 14:33 | Jacob Wieland - Spirent | Fixed in Version | => v4.8.1 (published 2016-07)
02-11-2015 14:33 | Jacob Wieland - Spirent | Resolution | open => fixed
02-11-2015 14:33 | Jacob Wieland - Spirent | Status | resolved => feedback
02-11-2015 14:33 | Jacob Wieland - Spirent | Resolution | fixed => reopened
02-11-2015 14:34 | Jacob Wieland - Spirent | Status | feedback => resolved
02-11-2015 14:34 | Jacob Wieland - Spirent | Resolution | reopened => fixed
02-11-2015 14:34 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
16-12-2015 11:03 | Gyorgy Rethy | Note Added: 0013636 |
16-12-2015 11:03 | Gyorgy Rethy | Status | resolved => feedback
16-12-2015 11:55 | Jacob Wieland - Spirent | Note Added: 0013637 |
16-12-2015 12:00 | Jacob Wieland - Spirent | Note Edited: 0013637 | bug_revision_view_page.php?bugnote_id=13637#r246
16-12-2015 12:01 | Jacob Wieland - Spirent | Note Edited: 0013637 | bug_revision_view_page.php?bugnote_id=13637#r247
18-07-2016 11:20 | Jens Grabowski | Assigned To | Gyorgy Rethy => KristÃ³f Szabados
18-07-2016 11:20 | Jens Grabowski | Status | feedback => assigned
18-07-2016 11:20 | Jens Grabowski | Status | assigned => feedback
22-07-2016 13:21 | KristÃ³f Szabados | File Added: CR6801_resolution_v5.docx |
22-07-2016 13:23 | KristÃ³f Szabados | Note Added: 0014037 |
17-08-2016 10:47 | Jacob Wieland - Spirent | Target Version | v4.8.1 (published 2016-07) => v4.9.1(ongoing)
17-08-2016 11:02 | Jacob Wieland - Spirent | Status | feedback => resolved
17-08-2016 11:02 | Jacob Wieland - Spirent | Fixed in Version | v4.8.1 (published 2016-07) => v4.9.1(ongoing)
17-08-2016 11:02 | Jacob Wieland - Spirent | Assigned To | KristÃ³f Szabados => Gyorgy Rethy
18-11-2016 08:24 | KristÃ³f Szabados | Assigned To | Gyorgy Rethy => KristÃ³f Szabados
18-11-2016 08:24 | KristÃ³f Szabados | Status | resolved => feedback
18-11-2016 08:24 | KristÃ³f Szabados | Resolution | fixed => reopened
18-11-2016 08:42 | KristÃ³f Szabados | Status | feedback => assigned
18-11-2016 08:42 | KristÃ³f Szabados | Fixed in Version | v4.9.1(ongoing) =>
18-11-2016 08:42 | KristÃ³f Szabados | Target Version | v4.9.1(ongoing) => Next version (to be defined)
18-11-2016 08:43 | KristÃ³f Szabados | Note Added: 0014322 |
16-07-2017 13:10 | KristÃ³f Szabados | Relationship added | related to 0007693
28-07-2017 12:36 | Jens Grabowski | Project | Part 01: TTCN-3 Core Language => Ext Pack: Object-oriented features (ES 203 790)
28-07-2017 12:36 | Jens Grabowski | Category | New Feature => General
27-10-2017 11:20 | KristÃ³f Szabados | Relationship added | related to 0007679
27-10-2017 11:21 | KristÃ³f Szabados | Note Added: 0014910 |
16-04-2018 11:55 | Jens Grabowski | Status | assigned => closed
16-04-2018 11:56 | Jens Grabowski | Note Added: 0015080 |

Notes

(0012342)
Jacob Wieland - Spirent
10-10-2014 09:46

Sounds like a very reasonable proposal/concept to me.

(0013042)
Gyorgy Rethy
03-08-2015 15:25

STF discussion 03-08-2015: no consensus on the current proposal. It is felt to be restrictive to one case, maybe a more generic approach could be though about. Consider possible alternatives at the STF session in October.

(0013363)
Jacob Wieland - Spirent
13-10-2015 10:35

I have uploaded a PP-presentation discussing the different issues and possible solutions of private component members. Please review so we can use this as a basis for discussion.

(0013387)
Gyorgy Rethy
14-10-2015 15:30

STF discussion: - go for solution 1.5: private data can be accessed by functions complying to all conditions: - having the concrete comp. type in their runs on clause - are in the same module as the component type definition - identified by an "accessor" modifier

(0013394)
Jacob Wieland - Spirent
15-10-2015 11:53

please review

(0013423)
Jens Grabowski
16-10-2015 09:14

See Comments in attached file. There was the discussion to deprecate indirect compatability. Maybe we should discuss this again.

(0013424)
Jacob Wieland - Spirent
16-10-2015 10:27

uploaded version addressing Jens's comments

(0013425)
Jacob Wieland - Spirent
16-10-2015 10:27

please review and resolve

(0013436)
Gyorgy Rethy
02-11-2015 13:28

CR6801_resolution_v3.docx: The text with yellow background in clause 6.3.3(about implicit type compatibility) should be moved to a new clause G.12; otherwise OK with me, only editorial changes.

(0013443)
Jacob Wieland - Spirent
02-11-2015 14:33

resolved according to last comment (also removed the NOTEs as they were only highlighting the difference between the new and the deprecated compatibility)

(0013636)
Gyorgy Rethy
16-12-2015 11:03

Sorry, we have a problem with the @accessor modifyer. The problem is that private variables are used so widely that the @accessor restriction is practically impossible to introduce at this stage.
@accessor in fact "sort" the functions/atsteps within the module (in which the component type is defined) to the ones that are allowed to directly access the private definitions and the ones which are disallowed. However, in practice it would solve a null problem, as one module is always a responsibility of one person or team. Therefore, in practice, this kind of sorting is not needed.

(0013637)
Jacob Wieland - Spirent
16-12-2015 11:55 (edited on: 16-12-2015 12:01)

I thought we discussed this at length and made a decision.
Of course, the usual pattern of using the publicly defined variables of a component does not work anymore, so this is not a backward-compatibility feature.
It is a feature for the allowing to define proper APIs in the future, which at the moment is not possible.
If, if I understand you correctly, you want to implicitly turn all functions inside the same module as the component containing the private variables (which, I guess, is a proprietary feature in your tool?) into implicit accessor functions for their runs on type, this incurs implicit restrictions on all functions using these functions (i.e. the previous lax component-runs-on compatibility rules cannot be used anymore).
In principle, I have no problem with that, but it breaks your usual preference regarding implicitness vs. explicitness.

(0014037)
KristÃ³f Szabados
22-07-2016 13:23

after my conversation with Jacob I have updated the proposal: functions with the @accessor modifier are no longer required to reside in the same module as the component they are running on, they can also reside in friend modules of the component's module.

(0014322)
KristÃ³f Szabados
18-11-2016 08:43

re-opened and shifted for next year. We should reconsider this CR together with next year's Object Orientation topic.

(0014910)
KristÃ³f Szabados
27-10-2017 11:21

This CR will be solved as part of the Object-Oriented Extension (CR7679)

(0015080)
Jens Grabowski
16-04-2018 11:56

CR solved as part of the OO-extension.