ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790) |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0007870 | Ext Pack: Object-oriented features (ES 203 790) | [All Projects] General | public | 27-08-2019 11:48 | 28-12-2020 12:21 |
|
| Reporter | Jacob Wieland - Spirent | |
| Assigned To | Jens Grabowski | |
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | |
| Platform | | OS | | OS Version | |
| Product Version | V1.2.1 (published 2020-05) | |
| Target Version | V1.3.1 (ongoing) | Fixed in Version | | |
|
| Summary | 0007870: Allow definition of class properties |
| Description | A 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;
}
} |
| Steps To Reproduce | |
| Additional Information | |
| Tags | No tags attached. |
| Relationships | |
| Attached Files |  CR7870-1.docx (153,433) 12-10-2020 13:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=3964&type=bug
CR7870-2.docx (139,957) 07-12-2020 10:59
http://oldforge.etsi.org/mantis/file_download.php?file_id=3965&type=bug
CR7870-3.docx (156,726) 08-12-2020 13:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=3974&type=bug
CR7870-4.docx (204,111) 09-12-2020 08:37
http://oldforge.etsi.org/mantis/file_download.php?file_id=3978&type=bug
CR7870-5.docx (186,391) 09-12-2020 14:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=3981&type=bug |
|
| 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 | bug_revision_view_page.php?rev_id=499#r499 |
| 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 |
|
Notes |
|
|
|
|
STF-discussion: this is a maybe feature |
|
|
|
|
|
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? |
|
|
|
|
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. |
|
|
|
|
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. |
|
|
|
|
|
Moved some descriptions that were not really restrictions to the Semantic Description part. Fixed some typos, expandend the example a little bit. Please review |
|
|
|
|
|
Maybe there should be a @derived modifier for variables/properties that shall not be added as parameters to the implicit constructor. |
|
|
|
|
|
STF Discussion: Add restriction that index notation on properties is not allowed on the left hand side of assignments. |
|
|
|
|
|
STF Discussion: Initializer before Constructor |
|
|
|
|
|
STF Discussion: (1) Automatic properties need to be added to implicit constructors (2) Add internal modifier (@internal or @derived) |
|
|
|
|
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. |
|
|
|
|
|
I added the TCI section to the document. |
|
|
|
|
|
STF Discussion: Visibility should be considered in the proposal. |
|
|
|
|
Added visibility and BNF rules. Also changed/simplified syntactical structure.
Please review |
|
|
|
|
|
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. |
|
|
|
|
|