ETSI's Bug Tracker - TTCN-3 Change Requests
View Issue Details
0008113TTCN-3 Change RequestsNew Featurepublic17-08-2022 07:1426-01-2024 16:27
Matthias Simon 
Jens Grabowski 
normalminorhave not tried
assignedopen 
New Extension
Nokia -- Matthias Simon
0008113: Type traits and user defined methods
Type traits allow to compose behavior in a lightweight, but powerful way.

## Methods

This extensions allows to specify methods for any user defined types. The
receiver type is specified using the "for" keyword. Inside the behavior the
receiver value is accessible via "this" symbol:

        module Example {
        type integer Timestamp
        function year() for Timestamp return string {
            return int2str(1970+this/SECONDS_PER_YEAR);
        }

        control {
            const Timestamp t := 1660681400;
            log(t.year()) // logs "2022"
        }
    }


## Traits

A trait is a set of methods and can be defined using the "trait" keyword:

    trait Stringer {
        function String() charstring;
    }

A variable of a trait type can hold any value that implements the trait:

    module Example {

        type record Point2D { integer x, integer y }
        function string() for Point3D return charstring {
            return sprintf("(%d|%d)", this.x, this.y)
        }

        type record Point3D { integer x, integer y, integer z }
        function string() for Point2D return charstring {
            return sprintf("(%d|%d|%d)", this.x, this.y, this.z)
        }

        trait Stringer {
            function string() charstring;
        }

        function logPoints(Stringer s) {
            log(s.string())
        }

        control {
            var Point2D p1 := {1,2};
            var Point3D p2 := {1,2,3}

            logPoints(p1); // okay because Point2D implements Stringer trait
            logPoints(p2); // okay because Point3D also implements Stringer trait
        }
    }


## Embedding

When the field name is omitted, the field is called an embedded field:

    type integer Timestamp;
    external function year() for Timestamp return charstring;

    type record Date {
        Timestamp, // embedded field
        charstring zone // regular field
    }


An embedded field is accessible by its type name:

    var Data d := { Timestamp := 1660681400, zone := "GMT+2" };
    d.Timestamp := d.Timestamp + 3600;


Embedded fields must be unique:

    type record Date {
        Timestamp,
        Timestamp // not allowed.
    }


Methods of an embedded field are promoted and become methods of the embedding type:

    var Data d := { Timestamp := 1660681400, zone := "GMT+2" };
    log(d.year()); // year is a promoted method implemented by the Timestamp type


Conflicting promoted methods have to be resolved explicitly:

    type integer Duration;
    external function year() for Duration return charstring;

    type record Event {
        Timestamp,
        Duration
    }

    // Timestamp and Duration both provide a "year"-method. Event type need
    // to resolve this conflict explicitly:
    function year() for Event return charstring {
        return sprintf("start=%s, duration=%s", this.Timestamp, this.Duration)
    }


## Notes and Open Questions

* Should we call it "trait" or rather "interface" like in Java, C# and Go?
* Should we support default implementations for traits (requires "implements" keyword)?
No tags attached.
Issue History
17-08-2022 07:14Matthias SimonNew Issue
17-08-2022 07:16Matthias SimonDescription Updatedbug_revision_view_page.php?rev_id=587#r587
17-08-2022 09:53Jens GrabowskiNote Added: 0016228
17-08-2022 09:53Jens GrabowskiAssigned To => Matthias Simon
17-08-2022 09:53Jens GrabowskiStatusnew => assigned
08-11-2022 08:15Matthias SimonNote Added: 0016267
08-11-2022 08:22Matthias SimonNote Edited: 0016267bug_revision_view_page.php?rev_id=595
08-11-2022 08:23Matthias SimonNote Edited: 0016267bug_revision_view_page.php?rev_id=596
08-11-2022 08:25Matthias SimonNote Edited: 0016267bug_revision_view_page.php?rev_id=597
10-11-2022 09:05Matthias SimonNote Edited: 0016267bug_revision_view_page.php?rev_id=600
10-11-2022 09:24Matthias SimonNote Deleted: 0016267
10-11-2022 09:52Matthias SimonNote Added: 0016287
10-11-2022 10:06Matthias SimonNote Edited: 0016287bug_revision_view_page.php?bugnote_id=16287#r602
10-11-2022 10:46Tomas UrbanNote Added: 0016290
10-11-2022 12:50Matthias SimonNote Edited: 0016287bug_revision_view_page.php?bugnote_id=16287#r603
07-12-2022 08:26Jens GrabowskiNote Added: 0016363
12-12-2022 09:01Matthias SimonNote Added: 0016382
12-12-2022 14:37Matthias SimonNote Added: 0016388
20-12-2022 11:45Jens GrabowskiNote Added: 0016437
08-11-2023 13:01Jens GrabowskiNote Added: 0016552
08-11-2023 13:01Jens GrabowskiAssigned ToMatthias Simon => Jens Grabowski
26-01-2024 16:27Olivier GenoudNote Added: 0016607

Notes
(0016228)
Jens Grabowski   
17-08-2022 09:53   
TTF discussion: CR should be splitted into Methods & Traits and Embedded Fields. Matthias will make more complete proposals. Questions to be answered are related to import and type compatibility.
(0016287)
Matthias Simon   
10-11-2022 09:52   
(edited on: 10-11-2022 12:50)
What syntax for defining methods do your prefer?

# Free floating (like in Go, Perl, ...)

Example:
    function F() for T runs on C return boolean {
        return this > 5;
    }

Variations:
    function F() with T ...
    function F() extends T ...
    function F() on T ...
    function F() to T ...
    function F() at T ...
    function F() in T ...
    function F() -> T ...
    function F() => T ...
    on T function F() ...
    function for T F() ...

     
# Qualified names (like in C++)

Example:
    function T::F() runs on C return boolean {
        return this > 5;
    }

Variations:
    function T.F() ...
    function T:F() ...


# Nested declarations (like in Java, Python, ...)

Example:
    type record T {
        integer x,
        function F() runs on C return boolean { return true },
        integer y
    }

    type integer I8 (-127..128) {
        function F() runs on C return boolean { return true };
    }


# Dedicated method block

Example:
    type record T {
        integer x,
        integer y
    } with {
        function F() runs on C return boolean { return true };
    }

    type integer I8 (-127..128) with {
        function F() runs T return boolean { return true };
    }

Variations:
    type integer I8 extends { ... }
    type integer I8 implements { ... }
    type integer I8 group { ... }
    type integer I8 bind { ... }
    type integer I8 connect { ... }

(0016290)
Tomas Urban   
10-11-2022 10:46   
This is a topic for a discussion.

Free floating syntax resembles what we already have in TTCN-3. It can extend built-in types as well. However, there are two major problems that are not easy to resolve (valid for qualified names too):
1. Import of traits, especially when they are defined in a different module than the type (could be resolved by dedicated import rules)
2. Violation of scoping principles of TTCN-3: So far all lower scopes are declared inside a definition. Using free floating could lead to traits with the same name but different functionality being present in more than one module and we would need a whole set of rule for handling that.

For these reasons, I would prefer an encapsulation approach. Out of the proposed options I like nested declarations more, because the syntax doesn't use excess symbols.
(0016363)
Jens Grabowski   
07-12-2022 08:26   
TTF discussion: Open questions are related to syntax and semantics. Unclear where to put this CR. May become part of core language or may become part of the OO extension. Resolution of issues should be discussed in the scope of language renovation.
(0016382)
Matthias Simon   
12-12-2022 09:01   
Split of embedded fields part: http://oldforge.etsi.org/mantis/view.php?id=8154 [^]
(0016388)
Matthias Simon   
12-12-2022 14:37   
Split of methods part: http://oldforge.etsi.org/mantis/view.php?id=8156 [^]
(0016437)
Jens Grabowski   
20-12-2022 11:45   
TTF discussion: Proposal will not be finalized and agreed upon until end of year. Proposal will be prepared until end of the year. To be shifted into the next TTF.
(0016552)
Jens Grabowski   
08-11-2023 13:01   
TTF discussion: To be discussed in the scope of OO features in new major release.
(0016607)
Olivier Genoud   
26-01-2024 16:27   
We assume/expect that this CR will not become part of the core language but will become part of an extension or be added to an extension (e.g. OO extension).