ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0005946 | Part 06: TTCN-3 Control Interface | Technical | public | 15-10-2011 18:03 | 10-08-2012 12:08

Reporter | Mateusz Pusz |
Assigned To | Ina Schieferdecker |
Priority | normal | Severity | block | Reproducibility | N/A
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v4.5.1 (published 2013-04) | Fixed in Version | v4.5.1 (published 2013-04) |
Clause Reference(s) | TRI 8.5.2, TCI 10.5.2
Source (company - Author) | Mateusz Pusz/freettcn

Summary | 0005946: TRI & TCI identifiers in C++ interface mapping wrongly defined

Description

Some TRI and TCI interfaces C++ mappings inherit privately from TRI::QualifiedName. That makes impossible to call any of its interface methods. To make it straight lets assume that TM just received TciTestCaseIdList from TciTmRequired::tciGetTestCases() and wants to present the names to the user. How is it supposed to do it if it does not have the access to private interface of TciTestCaseId class (because public interface of QualifiedName ends as private one in privately inherited child class)? I think that aggregation:
class TciTestCaseId {
.....
const QualifiedName &id() const;
.....
};
or public inheritance if really needed:
class TciTestCaseId : public QualifiedName {
.....
};
should be used here to achieve the goal. Another issue here is the existence of non-virtual cloneQualifiedName() method which makes it not only unusable (no-one have access to it) but also unimplementable as you cannot create the same object from that level in inheritance hierarchy (object slicing).
Even with above problem solved the class does not have any virtual method which makes it really hard to implement its methods as the class does not have any internal members. Because of that the developer is forced to do some external database with contents of those classes (like a map of QualifiedName pointers pointing to its content) and use it with every access to the class interface. It is why I think all methods in that class should be done pure virtual.
I suggest:
1. Making all methods in QualifiedName virtual and pure virtual (see https://github.com/mpusz/FreeTTCN/blob/d2ff73bbb9f4bb5e49b5cabe2c156512e456056c/freettcn/lib/include/freettcn/etsi/types.h#L60 [^])
2. Make IDs inherit (TTCN_ID_IFACE_FIXED_1) or aggregate (TTCN_ID_IFACE_FIXED_2) QualifiedName (see https://github.com/mpusz/FreeTTCN/blob/d2ff73bbb9f4bb5e49b5cabe2c156512e456056c/freettcn/lib/include/freettcn/etsi/tci.h [^] and https://github.com/mpusz/FreeTTCN/blob/d2ff73bbb9f4bb5e49b5cabe2c156512e456056c/freettcn/lib/include/freettcn/etsi/tri.h [^])
I personaly think that aggregation is better here and will make the interface more consistent with other classes like TriComponentId (https://github.com/mpusz/FreeTTCN/blob/d2ff73bbb9f4bb5e49b5cabe2c156512e456056c/freettcn/lib/include/freettcn/etsi/tri.h#L66 [^]). However both solutions will make the interface implementable,
Best
Mat

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

Relationships

parent of | 0006257 | closed | Ina Schieferdecker | Part 05: TTCN-3 Runtime Interface | TRI & TCI identifiers in C++ interface mapping wrongly defined

Attached Files | CR_5946_resolution_v1.docx (45,798) 12-07-2012 16:32 http://oldforge.etsi.org/mantis/file_download.php?file_id=2692&type=bug

Issue History
Date Modified | Username | Field | Change
15-10-2011 18:03 | Mateusz Pusz | New Issue |
15-10-2011 18:03 | Mateusz Pusz | Clause Reference(s) | => TRI 8.5.2, TCI 10.5.2
15-10-2011 18:03 | Mateusz Pusz | Source (company - Author) | => Mateusz Pusz/freettcn
15-10-2011 21:05 | Mateusz Pusz | Note Added: 0010322 |
15-10-2011 21:07 | Mateusz Pusz | Note Edited: 0010322 |
28-11-2011 16:16 | Gyorgy Rethy | Project | TTCN-3 Change Requests => Part 06: TTCN-3 Control Interface
28-11-2011 16:17 | Gyorgy Rethy | Note Added: 0010360 |
30-11-2011 11:01 | Ina Schieferdecker | Assigned To | => Ina Schieferdecker
30-11-2011 11:01 | Ina Schieferdecker | Status | new => assigned
30-11-2011 11:01 | Ina Schieferdecker | Target Version | => v4.7.1 (published 2015-06)
12-07-2012 14:10 | Ina Schieferdecker | Assigned To | Ina Schieferdecker => Tomas Urban
12-07-2012 16:32 | Tomas Urban | File Added: CR_5946_resolution_v1.docx |
12-07-2012 16:42 | Tomas Urban | Note Added: 0010898 |
12-07-2012 17:01 | Tomas Urban | Status | assigned => feedback
13-07-2012 12:13 | Tomas Urban | Status | feedback => resolved
13-07-2012 12:13 | Tomas Urban | Resolution | open => fixed
09-08-2012 14:43 | Tomas Urban | Assigned To | Tomas Urban => Ina Schieferdecker
09-08-2012 14:43 | Tomas Urban | Status | resolved => feedback
09-08-2012 14:43 | Tomas Urban | Resolution | fixed => reopened
09-08-2012 14:43 | Tomas Urban | Note Added: 0011009 |
09-08-2012 14:44 | Tomas Urban | Status | feedback => assigned
09-08-2012 14:44 | Tomas Urban | Resolution | reopened => open
10-08-2012 12:06 | Ina Schieferdecker | Issue cloned: 0006257 |
10-08-2012 12:06 | Ina Schieferdecker | Relationship added | parent of 0006257
10-08-2012 12:08 | Ina Schieferdecker | Note Added: 0011027 |
10-08-2012 12:08 | Ina Schieferdecker | Status | assigned => closed
10-08-2012 12:08 | Ina Schieferdecker | Resolution | open => fixed
10-08-2012 12:08 | Ina Schieferdecker | Fixed in Version | => Edition 4.5.1

Notes

(0010322)
Mateusz Pusz
15-10-2011 21:05 (edited on: 15-10-2011 21:07)

BTW example implementation for both approaches can be found here: https://github.com/mpusz/FreeTTCN/blob/d2ff73bbb9f4bb5e49b5cabe2c156512e456056c/freettcn/lib/include/freettcn/ttcn3/ttcnId.h [^]

(0010360)
Gyorgy Rethy
28-11-2011 16:17

STF discussion 28/11: Discuss it with tool vendors.

(0010898)
Tomas Urban
12-07-2012 16:42

The proposed resolution is to change the methods of QualifiedName to pure virtual and change the definition of the classes derived from QualifiedName (i.e. TriFunctionId, TriSignatureId, TriTestCaseId, TciBehaviourId, TciTestCaseId, TciModuleParameterId) so that the inheritance is public.
The changes were kept on the necessary minimum in order to preserve backwards compatibility of the C++ mapping. For that reason, it was not possible to opt for the aggregate solution or to unify naming of cloning methods.
Tool vendors will be notified about the change. Final decition about the proposal shall be made based on the feedback from the vendors.

(0011009)
Tomas Urban
09-08-2012 14:43

No significant feedback was received from the vendors, so it seems we can go on with changing the standard. Ina, could you please check the proposed resolution?

(0011027)
Ina Schieferdecker
10-08-2012 12:08

Implemented as proposed.