Logo etsi

ETSI's Bug Tracker

Notice: information submitted on the ETSI issue Tracker may be incorporated in ETSI publication(s) and therefore subject to the ETSI IPR policy.

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007870Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic27-08-2019 11:4828-12-2020 12:21
ReporterJacob Wieland - Spirent 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionV1.2.1 (published 2020-05) 
Target VersionV1.3.1 (ongoing)Fixed in Version 
Summary0007870: Allow definition of class properties
DescriptionA class property is a class member which is referenced like a record field for reading and writing with the dotted notation, but implemented via getter and setter functions that are provided in the definition of the property (allowing value checking/normalization/conversion when setting a value and on-the-fly computation when getting the value).

In C#, this looks like this:

[<visibility>] <type> <identifier> {
  [<getter>]
  [<setter>]
} [= <initial_value>];

<getter> and <setter> have different possible syntaxes:

- [<visibility>] get { <body_returning value> }
- [<visibility>] set { <body assigning value> }
- [<visibility>] get => <result_value>;
- [<visibility>] set => <value_assignment>;
- [<visibility>] get;
- [<visibility>] set;

In the case that there is only a getter there is also a short version

<visibility> <type> <identifier> => <result_value>;

Thus, I propose the following syntaxes for TTCN-3 to define properties.

var <template_modifier> <type>
@property <modifiers>
{<identifier> [<property_body>] [= <initial_value>] [","]}+ [";"]

<property_body> has the following structure:
"=>" <expression> |
"{" (<getter> [<setter>] | <setter> [<getter>) "}"

<getter> has the following structure:
<modifiers> @get ("=>" <expression> [";"] | "{" { <statement> }+ "}")

<setter> has the following structure:
<modifiers> @set ("=>" <assignment> [";"] | "{" { <statement> } "}")

We don't allow the { get; set; } syntax for automatic properties (without backing extra fields), instead, a @property variable without a <property_body> is treated as an automatic read/write property.

When a property variable with a given <setter> is accessed on the left hand side of an assignment, the setter statements will be evaluated with the formal parameter 'value' being bound to the actual parameter of the right-hand-side. Accessing a non-automatic property value without a given <setter> on the left-hand side shall result in an error.

When a property variable with a given <getter> is evaluated on the right hand side, the getter statements or expression will be evaluated and the resulting value will be the result of the evaluation. Accessing a non-automatic property value without a given <getter> on the right-hand side shall result in an error.

Properties can be declared public and can be overridden by subclasses with the same visibility restrictions as for methods.

Properties as well as their getters and setters can also be declared @abstract inside @abstract classes. If a property is declared abstract, the getter and/or setter does not need a body.

A property, as well as getters and setters can also be declared @final. If a property is declared @final then neither the getter nor the setter can be overridden, otherwise, if a getter or setter itself is declared @final, then it shall not be overridden.

Properties can be overridden by subclasses if they are not declared @final.

EXAMPLE:

type class MyPropertyClass {
  private var charstring v_color;

  // read-write property with backing variable
  public var charstring @property color {
   // getter in short form
   @get => v_color;
   @set {
     if (isColor(value)) { v_color := value }
     else { raise v_color&" is not a color" }
    }
  }
  
  // read-only property with computed value
  public var RGB @property rgb {
     // getter in long form
     @get { return computeRGB(v_color) }
  }
  
  // automatic property with initial value
  public var float @property size := 0.0;

  // read-only property with derived result in short form
  public var float @property square => size*size;

  // write-only property with short form
  public var float @property half_size {
    @set => size := half_size*2.0;
  }
}
TagsNo tags attached.
Attached Filesdocx file icon CR7870-1.docx [^] (153,433 bytes) 12-10-2020 13:39
docx file icon CR7870-2.docx [^] (139,957 bytes) 07-12-2020 10:59
docx file icon CR7870-3.docx [^] (156,726 bytes) 08-12-2020 13:30
docx file icon CR7870-4.docx [^] (204,111 bytes) 09-12-2020 08:37
docx file icon CR7870-5.docx [^] (186,391 bytes) 09-12-2020 14:41

- Relationships

-  Notes
(0015475)
Jacob Wieland - Spirent (reporter)
27-08-2019 14:23

STF-discussion: this is a maybe feature
(0015791)
Tomas Urban (developer)
12-10-2020 13:42

I put together a basic draft of the functionality. Although there are some important parts still missing (BNF, TCI), I think it is worth to first check if the proposal goes in the right direction. Jacob, could you please comment the proposed rules?
(0015793)
Jacob Wieland - Spirent (reporter)
07-12-2020 10:32

The following things need to be discussed.

What about the setters of list/array properties, is it allowed to use the index operation on them and if so, how to reference the index in the setter?

Similarly, is it allowed to use a property in the middle of a dotted notation on the left hand side of an assignment? And if so, what does it mean? Does it invoke the getter, changes the resulting sub-value in the result and then invokes the setter with the changed value? If so, this approach could also be used to deal with question 1.
(0015794)
Jacob Wieland - Spirent (reporter)
07-12-2020 10:38

We should also discuss the following:

. The initial value is automatically passed to the setter when an instance of the defining class is created. This automatic invocation takes place after execution of a constructor of the parent class and before execution of the constructor of the defining class. Properties are automatically initialized in the declaration order.

I think, since properties are often derived from other variables, they should be initialized after the constructor of the declaring class so that they can safely be executed. There should also be a restriction that the constructor or any non-property member shall reference a property member on the right hand side.
(0015795)
Jacob Wieland - Spirent (reporter)
07-12-2020 11:00

Moved some descriptions that were not really restrictions to the Semantic Description part. Fixed some typos, expandend the example a little bit. Please review
(0015796)
Jacob Wieland - Spirent (reporter)
07-12-2020 11:03

Maybe there should be a @derived modifier for variables/properties that shall not be added as parameters to the implicit constructor.
(0015807)
Jens Grabowski (manager)
08-12-2020 09:19

STF Discussion: Add restriction that index notation on properties is not allowed on the left hand side of assignments.
(0015808)
Jens Grabowski (manager)
08-12-2020 09:39

STF Discussion: Initializer before Constructor
(0015809)
Jens Grabowski (manager)
08-12-2020 09:49

STF Discussion: (1) Automatic properties need to be added to implicit constructors (2) Add internal modifier (@internal or @derived)
(0015813)
Tomas Urban (developer)
08-12-2020 13:39

I made those two small changes we discussed at the meeting. The initialization didn't require any change as the original design used initialization before the constructor.

Since there's no section on member variables, I added the @internal modifier description only to the section describing constructors (and syntax description of properties).

Jacob, please check if these changes are fine by you. However, the document is still quite far from final. Since you mentioned that you didn't have many tasks assigned to you, could you please also create the BNF and eventually address the visibility issue (especially visibility on the getter and setter level).

I could meanwhile deal with the TCI.
(0015820)
Tomas Urban (developer)
09-12-2020 08:38

I added the TCI section to the document.
(0015823)
Jens Grabowski (manager)
09-12-2020 09:16

STF Discussion: Visibility should be considered in the proposal.
(0015825)
Jacob Wieland - Spirent (reporter)
09-12-2020 14:38

Added visibility and BNF rules. Also changed/simplified syntactical structure.

Please review
(0015826)
Tomas Urban (developer)
09-12-2020 15:10

It looks fine to me. Could you please check the TCI section and either assign to Kristof for the final check or mark it directly as resolved if you find no issues.
(0015841)
Jacob Wieland - Spirent (reporter)
10-12-2020 13:31

TCI part looks fine.

- Issue History
Date Modified Username Field Change
27-08-2019 11:48 Jacob Wieland - Spirent New Issue
27-08-2019 13:04 Jacob Wieland - Spirent Description Updated View Revisions
27-08-2019 14:23 Jacob Wieland - Spirent Note Added: 0015475
27-08-2019 15:06 Jacob Wieland - Spirent Assigned To => Jens Grabowski
27-08-2019 15:06 Jacob Wieland - Spirent Status new => assigned
14-08-2020 11:20 Jens Grabowski Assigned To Jens Grabowski => Tomas Urban
12-10-2020 13:39 Tomas Urban File Added: CR7870-1.docx
12-10-2020 13:42 Tomas Urban Note Added: 0015791
12-10-2020 13:42 Tomas Urban Assigned To Tomas Urban => Jacob Wieland - Spirent
07-12-2020 10:32 Jacob Wieland - Spirent Note Added: 0015793
07-12-2020 10:38 Jacob Wieland - Spirent Note Added: 0015794
07-12-2020 10:59 Jacob Wieland - Spirent File Added: CR7870-2.docx
07-12-2020 11:00 Jacob Wieland - Spirent Note Added: 0015795
07-12-2020 11:00 Jacob Wieland - Spirent Assigned To Jacob Wieland - Spirent => Tomas Urban
07-12-2020 11:03 Jacob Wieland - Spirent Note Added: 0015796
08-12-2020 09:19 Jens Grabowski Note Added: 0015807
08-12-2020 09:39 Jens Grabowski Note Added: 0015808
08-12-2020 09:49 Jens Grabowski Note Added: 0015809
08-12-2020 13:30 Tomas Urban File Added: CR7870-3.docx
08-12-2020 13:39 Tomas Urban Note Added: 0015813
08-12-2020 13:39 Tomas Urban Assigned To Tomas Urban => Jacob Wieland - Spirent
09-12-2020 08:37 Tomas Urban File Added: CR7870-4.docx
09-12-2020 08:38 Tomas Urban Note Added: 0015820
09-12-2020 09:16 Jens Grabowski Note Added: 0015823
09-12-2020 14:37 Jacob Wieland - Spirent File Added: CR7870-5.docx
09-12-2020 14:38 Jacob Wieland - Spirent Note Added: 0015825
09-12-2020 14:38 Jacob Wieland - Spirent Assigned To Jacob Wieland - Spirent => Tomas Urban
09-12-2020 14:38 Jacob Wieland - Spirent Status assigned => confirmed
09-12-2020 14:41 Jacob Wieland - Spirent File Deleted: CR7870-5.docx
09-12-2020 14:41 Jacob Wieland - Spirent File Added: CR7870-5.docx
09-12-2020 15:10 Tomas Urban Note Added: 0015826
09-12-2020 15:10 Tomas Urban Assigned To Tomas Urban => Jacob Wieland - Spirent
10-12-2020 13:31 Jacob Wieland - Spirent Note Added: 0015841
10-12-2020 13:31 Jacob Wieland - Spirent Status confirmed => resolved
10-12-2020 13:31 Jacob Wieland - Spirent Resolution open => fixed
10-12-2020 13:31 Jacob Wieland - Spirent Assigned To Jacob Wieland - Spirent => 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 12:21 Jens Grabowski Status resolved => closed


MantisBT 1.2.14 [^]
Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker