0007871: Class templates to be added to the language?

(0015534)
Jacob Wieland - Spirent (reporter)
17-12-2019 08:34

Interesting in this regard would be to look at Class patterns introduced by Java or Scala.

(0015843)
Jacob Wieland - Spirent (reporter)
10-12-2020 14:10

The only idea that I can come up with so far that is in sync with the design principles of TTCN-3 is to allow compound-assignment-notation as class templates.

Only those fields that are to be constrained should have to be mentioned, all unmentioned fields should implicitly be 'don't care'. That way, a template for class A can also be used for all subclasses of A that add additional fields. Otherwise, you would always have to use the mofifies contruct like A:modifies ? := { ... } instead of simply A:{ ... }

Only field members should be referenced on the left sides of the field assignments inside the compound assignment.

Example:

type class Pair { var integer a, b }

template Pair t := { a := (1 .. 20) }

type class Triple extends Pair { var integer c }

match(Triple.create(1,2,3), t) // returns true

Additionally, method calls of non-void methods of the class could also be allowed on the left hand side of the assignment notation.

For example:

type class @abstract Shape { function @abstract area() return float; }

template Shape smallShape := { area() := (0 .. 20.0) }

smallShape would match for all objects whose class is derived from Shape and where the result of the method call to area() fulfills the constraint.

For this extension, of course, multiple "assignments" for the same method shall be allowed in the compound assignment. As always, the semantics would be that for all assignments the constraint needs to be fulfilled so that the template matches.

Drawback here is that empty templates that do not match anything can be declared, as in

template Shape empty := {
area() := (0.0 .. infinity),
area() := {-infinity .. !0.0)
}

A similar such conflict can occur between an assignment of a field member and a method-call constraint.

So, maybe this advanced assignment notation with method calls should only be added to the advanced matching package.

(0015844)
Jacob Wieland - Spirent (reporter)
10-12-2020 15:30
edited on: 10-12-2020 15:36

Probably only non-private fields should be possible to be used in class templates, as otherwise, private fields could be implicitly accessed.

Maybe this should even only be allowed for public property fields (and public methods), i.e. those things that you can access from outside.

(0015850)
Jacob Wieland - Spirent (reporter)
11-12-2020 12:49

Please review first draft.

(0015851)
Jacob Wieland - Spirent (reporter)
11-12-2020 12:50

TODO: BNF rules

(0015852)
Jacob Wieland - Spirent (reporter)
11-12-2020 13:05

TODO: Delete the sentence that there are no object/class templates.

(0015853)
Jacob Wieland - Spirent (reporter)
11-12-2020 13:07

Added second draft with additional restriction about object templates not being allowed to be used as values or converted into values.

Also added BNF rules (draft)

(0015854)
Jacob Wieland - Spirent (reporter)
11-12-2020 13:22

Replaced draft 2 with version with simpler BNF change that also does not introduce BNF ambiguity by changing only the rule for FieldSpec

(0015855)
Tomas Urban (developer)
11-12-2020 13:23

It seems fine to me. I only made two small changes, please check.

(0015856)
Jacob Wieland - Spirent (reporter)
11-12-2020 13:35

ok, also added the deletion of the restriction that there are no class templates to the draft, please check and resolve, if ok

(0015857)
Tomas Urban (developer)
11-12-2020 13:40

Reviewed, no issues found. The proposal is ready to be added to the next version of the specification.

Issue History
Date Modified	Username	Field	Change
27-08-2019 15:15	Jacob Wieland - Spirent	New Issue
27-08-2019 15:23	Jacob Wieland - Spirent	Assigned To	=> Jens Grabowski
27-08-2019 15:23	Jacob Wieland - Spirent	Status	new => assigned
17-12-2019 08:34	Jacob Wieland - Spirent	Note Added: 0015534
10-12-2020 14:10	Jacob Wieland - Spirent	Note Added: 0015843
10-12-2020 15:30	Jacob Wieland - Spirent	Note Added: 0015844
10-12-2020 15:36	Jacob Wieland - Spirent	Note Edited: 0015844	View Revisions
11-12-2020 11:07	Jens Grabowski	Assigned To	Jens Grabowski => Jacob Wieland - Spirent
11-12-2020 12:48	Jacob Wieland - Spirent	File Added: CR7871-1.docx
11-12-2020 12:49	Jacob Wieland - Spirent	Note Added: 0015850
11-12-2020 12:49	Jacob Wieland - Spirent	Assigned To	Jacob Wieland - Spirent => Tomas Urban
11-12-2020 12:50	Jacob Wieland - Spirent	Note Added: 0015851
11-12-2020 13:05	Jacob Wieland - Spirent	Note Added: 0015852
11-12-2020 13:06	Jacob Wieland - Spirent	File Added: CR7871-2.docx
11-12-2020 13:07	Jacob Wieland - Spirent	Note Added: 0015853
11-12-2020 13:21	Jacob Wieland - Spirent	File Deleted: CR7871-2.docx
11-12-2020 13:21	Jacob Wieland - Spirent	File Added: CR7871-2.docx
11-12-2020 13:22	Tomas Urban	File Added: CR7871-3.docx
11-12-2020 13:22	Jacob Wieland - Spirent	Note Added: 0015854
11-12-2020 13:23	Tomas Urban	Note Added: 0015855
11-12-2020 13:23	Tomas Urban	Assigned To	Tomas Urban => Jacob Wieland - Spirent
11-12-2020 13:23	Tomas Urban	Status	assigned => confirmed
11-12-2020 13:30	Tomas Urban	File Added: CR7871-4.docx
11-12-2020 13:34	Jacob Wieland - Spirent	File Added: CR7871-5.docx
11-12-2020 13:35	Jacob Wieland - Spirent	Assigned To	Jacob Wieland - Spirent => Tomas Urban
11-12-2020 13:35	Jacob Wieland - Spirent	Status	confirmed => assigned
11-12-2020 13:35	Jacob Wieland - Spirent	Note Added: 0015856
11-12-2020 13:35	Jacob Wieland - Spirent	Status	assigned => confirmed
11-12-2020 13:40	Tomas Urban	Note Added: 0015857
11-12-2020 13:40	Tomas Urban	Status	confirmed => resolved
11-12-2020 13:40	Tomas Urban	Resolution	open => fixed
11-12-2020 13:40	Tomas Urban	Assigned To	Tomas Urban => Jens Grabowski
17-12-2020 16:17	Gyorgy Rethy	Product Version	=> V1.2.1 (published 2020-05)
17-12-2020 16:17	Gyorgy Rethy	Target Version	=> V1.3.1 (ongoing)
28-12-2020 13:44	Jens Grabowski	Status	resolved => closed

Notes
(0015534) Jacob Wieland - Spirent (reporter) 17-12-2019 08:34	Interesting in this regard would be to look at Class patterns introduced by Java or Scala.

(0015843) Jacob Wieland - Spirent (reporter) 10-12-2020 14:10	The only idea that I can come up with so far that is in sync with the design principles of TTCN-3 is to allow compound-assignment-notation as class templates. Only those fields that are to be constrained should have to be mentioned, all unmentioned fields should implicitly be 'don't care'. That way, a template for class A can also be used for all subclasses of A that add additional fields. Otherwise, you would always have to use the mofifies contruct like A:modifies ? := { ... } instead of simply A:{ ... } Only field members should be referenced on the left sides of the field assignments inside the compound assignment. Example: type class Pair { var integer a, b } template Pair t := { a := (1 .. 20) } type class Triple extends Pair { var integer c } match(Triple.create(1,2,3), t) // returns true Additionally, method calls of non-void methods of the class could also be allowed on the left hand side of the assignment notation. For example: type class @abstract Shape { function @abstract area() return float; } template Shape smallShape := { area() := (0 .. 20.0) } smallShape would match for all objects whose class is derived from Shape and where the result of the method call to area() fulfills the constraint. For this extension, of course, multiple "assignments" for the same method shall be allowed in the compound assignment. As always, the semantics would be that for all assignments the constraint needs to be fulfilled so that the template matches. Drawback here is that empty templates that do not match anything can be declared, as in template Shape empty := { area() := (0.0 .. infinity), area() := {-infinity .. !0.0) } A similar such conflict can occur between an assignment of a field member and a method-call constraint. So, maybe this advanced assignment notation with method calls should only be added to the advanced matching package.

(0015844) Jacob Wieland - Spirent (reporter) 10-12-2020 15:30 edited on: 10-12-2020 15:36	Probably only non-private fields should be possible to be used in class templates, as otherwise, private fields could be implicitly accessed. Maybe this should even only be allowed for public property fields (and public methods), i.e. those things that you can access from outside.

(0015850) Jacob Wieland - Spirent (reporter) 11-12-2020 12:49	Please review first draft.

(0015851) Jacob Wieland - Spirent (reporter) 11-12-2020 12:50	TODO: BNF rules

(0015852) Jacob Wieland - Spirent (reporter) 11-12-2020 13:05	TODO: Delete the sentence that there are no object/class templates.

(0015853) Jacob Wieland - Spirent (reporter) 11-12-2020 13:07	Added second draft with additional restriction about object templates not being allowed to be used as values or converted into values. Also added BNF rules (draft)

(0015854) Jacob Wieland - Spirent (reporter) 11-12-2020 13:22	Replaced draft 2 with version with simpler BNF change that also does not introduce BNF ambiguity by changing only the rule for FieldSpec

(0015855) Tomas Urban (developer) 11-12-2020 13:23	It seems fine to me. I only made two small changes, please check.

(0015856) Jacob Wieland - Spirent (reporter) 11-12-2020 13:35	ok, also added the deletion of the restriction that there are no class templates to the draft, please check and resolve, if ok

(0015857) Tomas Urban (developer) 11-12-2020 13:40	Reviewed, no issues found. The proposal is ready to be added to the next version of the specification.

Relationships

ETSI's Bug Tracker