|
Notes |
|
|
|
|
Interesting in this regard would be to look at Class patterns introduced by Java or Scala. |
|
|
|
|
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. |
|
|
|
|
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.
|
|
|
|
|
|
Please review first draft. |
|
|
|
|
|
|
|
|
|
TODO: Delete the sentence that there are no object/class templates. |
|
|
|
|
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) |
|
|
|
|
|
Replaced draft 2 with version with simpler BNF change that also does not introduce BNF ambiguity by changing only the rule for FieldSpec |
|
|
|
|
|
It seems fine to me. I only made two small changes, please check. |
|
|
|
|
|
ok, also added the deletion of the restriction that there are no class templates to the draft, please check and resolve, if ok |
|
|
|
|
|
Reviewed, no issues found. The proposal is ready to be added to the next version of the specification. |
|
CR7871-1.docx (134,973) 11-12-2020 12:48