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

ID | Project | Category | View Status | Date Submitted | Last Update
0007679 | Ext Pack: Object-oriented features (ES 203 790) | [All Projects] General | public | 09-06-2017 05:07 | 07-05-2018 12:34

Reporter | Jacob Wieland - Spirent |
Assigned To | Jens Grabowski |
Priority | normal | Severity | major | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version |  | Fixed in Version |  |

Summary | 0007679: Class Concept to be added

Description

Currently the language already contains certain kinds of object classes like components, ports and timers which are passed by reference and used with object-oriented-like syntax in their operations (start,stop,running,send,receive,etc.)
Also, there is a demand to allow user-defined objects with encapsulated state and behavior that is not visible/accessible and public functionality that allows manipulation of that state.
Thus, a class concept shall be introduced to TTCN-3 that addresses this demand but also allows the expression of the existing concepts as special kinds of classes.
Features that the class concept need to encompass (to allow mapping of the old concepts to the new ones):
- constructors (create)
- readonly (dynamic) properties (like running, alive, started)
- methods without parameter lists (like stop, kill)
- events (like timeout, receive, getcall, getreply, catch, done, killed, check) with additional output channels (-> value, sender, param)
- polymorphic methods (like send, call, reply, raise)
The basic builtin class hierarchy would be:
object
- active object
- - timer
- - component
- port
- - message port
- - procedure port
- - mixed port (maybe extending both message and procedure port)
The instances of classes, in contrast to the values of data types are objects that are always passed by reference-value, i.e. the value that is passed to in parameters is a reference to the object given as actual parameter, not a copy of that object.
Members of objects can be accessed via dotted notation.
The basic syntax of a class definition could be something like:
type class <name> [extends <super_classes>] {
<member declarations>
}
It has to be discussed how clashing function definitions from two or more superclasses are to be handled.
Forcing the user to override these functions (with allowed access to the super-implementations) is probably the best way with the following restrictions.
Two classes containing a function of the same name can only be inherited together if the signature of the function is the same (or the formal parameter list of one is a prefix of the other and all additional formal parameters are either out parameters or in parameters with a default). If a function is overriding a function in an ancestor, its formal parameter list must the formal parameter list of the overriden function from as a prefix and all additional parameters must either be out parameters or in parameters with a default.
Example:
type class A {
function f(integer a)...
}
type class B {
function f(integer a, float b :- 0.0) ...
}
type class C extends A, B {
function f(integer a, float b, charstring c := "") ...
}
These restrictions ensure that whether an object of class C is used as an object of class A (in which only f(integer) can be called) or of class B (in which f(integer) and f(integer,float) can be called) all different versions of calling f are valid instances of the lowest function definition (the one in C).
For other non-private members than functions, the same restrictions as for members of component types apply, i.e. they have to be unique in their class hierarchy.
Special classes can be declared external. Both the state and the function of these classes are implemented outside of the language and their functionality provided via the Platform Adapter (x)triExternalFunction (the external functions get the object reference as their first parameter).
This allows platform native implementations like Collection types or other libraries to be lifted in an abstract way into TTCN-3 without the need to reimplement them in TTCN-3, providing the functionality without great loss of efficiency or tool independence.
Types defined by class definition are subtypes of their superclasses, e.g. their instances can be used as instances of their superclasses as well.
A component or port type definition is a syntactic shortcut of a class definition extending either the base component/port type (if no supertypes are given) or their supertypes with special functions that depend on the new component/port type. In case of the component type, the start function is overridden to allow only behaviors that run on that component type to be started.
type port P message { in <in_types>; out <out_types>; }
would be equivalent with something like:
type class P extends 'message port' {
@implicit function
send<<in_types> I, A>(template(value) I msg,
template(present) A 'to' := null);
@implicit @event
function receive<<out_types> O, A>(template(present) O msg,
template(present) A 'from' := ?,
out T 'value',
out A 'sender') return boolean;
}
where MessagePort is defined like:
type class 'message port' extends 'port' {
// message port specifics
}
type class 'port' extends 'active object' {
@implicit function checkstate(charstring state_kind) return boolean;
@implicit function 'stop';
@implicit function halt;
@implicit function start;
@implicit function clear;
}
type class 'active object' extends 'object' {
@implicit function 'running' return boolean;
}

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

Relationships

related to | 0007731 | closed | Jens Grabowski | Draft document for Object-oriented Extension
related to | 0007693 | closed | KristÃ³f Szabados | component members with visibility and functions inside the components
related to | 0006801 | closed | KristÃ³f Szabados | Visibility of component definitions

Attached Files

ToC-Draft-OO2.docx (29,920) 04-09-2017 12:11
http://oldforge.etsi.org/mantis/file_download.php?file_id=3675&type=bug
OO-Presentation.pptm (56,122) 07-09-2017 14:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=3682&type=bug
OO-Draft-3.docx (29,595) 25-10-2017 08:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=3688&type=bug
MTS-203790-00F_ed111v001.docx (168,418) 26-10-2017 09:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=3705&type=bug

Issue History
Date Modified | Username | Field | Change
09-06-2017 05:07 | Jacob Wieland - Spirent | New Issue |
09-06-2017 05:07 | Jacob Wieland - Spirent | Status | new => assigned
09-06-2017 05:07 | Jacob Wieland - Spirent | Assigned To | => Jacob Wieland - Spirent
09-06-2017 13:10 | Jacob Wieland - Spirent | Description Updated | bug_revision_view_page.php?rev_id=423#r423
25-07-2017 14:34 | Jens Grabowski | Note Added: 0014752 |
25-07-2017 16:21 | Jacob Wieland - Spirent | Note Added: 0014759 |
25-07-2017 16:44 | Jacob Wieland - Spirent | Note Added: 0014763 |
25-07-2017 16:54 | Jacob Wieland - Spirent | Note Added: 0014764 |
25-07-2017 17:07 | Jacob Wieland - Spirent | Note Edited: 0014759 | bug_revision_view_page.php?bugnote_id=14759#r430
26-07-2017 08:32 | Jacob Wieland - Spirent | Note Edited: 0014763 | bug_revision_view_page.php?bugnote_id=14763#r432
26-07-2017 08:36 | Jacob Wieland - Spirent | Note Edited: 0014764 | bug_revision_view_page.php?bugnote_id=14764#r434
04-09-2017 09:04 | Jens Grabowski | Project | TTCN-3 Change Requests => Ext Pack: Object-oriented features (ES 203 790)
04-09-2017 09:04 | Jens Grabowski | Category | New Feature => General
04-09-2017 12:11 | Jacob Wieland - Spirent | File Added: ToC-Draft-OO2.docx |
07-09-2017 14:43 | Jacob Wieland - Spirent | File Added: OO-Presentation.pptm |
24-10-2017 13:48 | Jens Grabowski | Note Added: 0014851 |
25-10-2017 08:30 | Jacob Wieland - Spirent | File Added: OO-Draft-3.docx |
25-10-2017 08:40 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Julien Deltour
25-10-2017 08:40 | Jacob Wieland - Spirent | Note Added: 0014857 |
26-10-2017 09:16 | Julien Deltour | File Added: MTS-203790-00F_ed111v001.docx |
27-10-2017 11:19 | KristÃ³f Szabados | Relationship added | related to 0007693
27-10-2017 11:20 | KristÃ³f Szabados | Relationship added | related to 0006801
04-12-2017 15:42 | Julien Deltour | Relationship added | related to 0007731
04-12-2017 15:43 | Julien Deltour | Note Added: 0014925 |
04-12-2017 15:43 | Julien Deltour | Status | assigned => confirmed
04-12-2017 15:43 | Julien Deltour | Assigned To | Julien Deltour => Jens Grabowski
04-12-2017 15:43 | Julien Deltour | Status | confirmed => assigned
07-05-2018 12:34 | Jens Grabowski | Status | assigned => closed
07-05-2018 12:34 | Jens Grabowski | Resolution | open => fixed

Notes

(0014752)
Jens Grabowski
25-07-2017 14:34

STF discussion: Jacob will provide a TTCN-3 OO code example.

(0014759)
Jacob Wieland - Spirent
25-07-2017 16:21 (edited on: 25-07-2017 17:07)

As per our discussion, we have identified a distinction between object-oriented operations between inter-component calls and intra-component calls.
Inter-component operations are start, running, done, stop, kill, killed, alive
An inter-component method call is the calling of a member-function inside a component context (or thread) to one of the components' objects. The set of components' objects are the component itself and all objects that it has created (component ports and timers as well as local objects) except other components.
For example:
external type class Stack<T> {
function push(T i);
function T pop();
}
type component StackComponent<T> {
var Stack<T> v_stack := Stack<T>.create;
}
In this scenario, a function that runs on StackComponent<T> would be allowed to call v_stack.push(t) and t := v_stack.pop()
I think it should be allowed to share references to inner-component objects, but only behavior running on the owning component is allowed to access the members while other behavior can only pass the reference around and compare it with other references of compatible type. This is similar to sharing component references where all you can access are the inter-component operations but not the members of the referenced component.

(0014763)
Jacob Wieland - Spirent
25-07-2017 16:44 (edited on: 26-07-2017 08:32)

For port types, all port operations (send,receive,stop,halt,running,etc.) are (external) (generic) members that can be used inside the owning component.
type class MessagePort<I,O> {
@implicit
function send(template(value) O msg, (ComponentType,address) 'to');
@implicit
@event
function receive(template(present) I msg,
out I 'value',
out (Componenttype,address), 'sender')
return boolean;
@remote
function start, stop, halt;
@remote
function running return boolean;
}
A declaration
type port P message { in I1, I2; out O1, O2 }
would be equivalent with
type class P extends MessagePort<(I1,I2), (O1, O2)>;

(0014764)
Jacob Wieland - Spirent
25-07-2017 16:54 (edited on: 26-07-2017 08:36)

For the moment, we have opted not to include multiple class inheritance into the OO language part.
A component type which extends multiple component types T1, ..., Tn will be mapped to a class derived from the first type T1 with all fields only inherited from T2,...,Tn copied into the class body.
For example:
type component A {
var integer a;
}
type copmponent B extends A {
var integer b;
}
type component C extends A {
var integer c;
}
type component D extends B, C {
var integer d;
}
would result in the following type class definitions:
type class A extends ComponentType {
var integer a;
}
type class B extends A {
var integer b;
}
type class C extends A {
var integer c;
}
type class D extends B {
var integer d;
var integer c;
// a from C is not copied because it is already inherited via B
}
For this to work, there needs to be a restriction on 'private' members that their names cannot clash (i.e. the same restriction as for non-private members applies). I think we should provide a new visibility modifier @invisible for that to avoid confusion with the normal understanding of 'private' (i.e. a name that is not visible anywhere outside the context which declares it).

(0014851)
Jens Grabowski
24-10-2017 13:48

STF decision: Textual proposal re-checked by Jacob and then assigned to Julien. Julien will put the text into the draft document.

(0014857)
Jacob Wieland - Spirent
25-10-2017 08:40

Please integrate the text from the latest Draft into the draft document.

(0014925)
Julien Deltour
04-12-2017 15:43

Full draft document has been created in a specific CR.