ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0007187 | Ext Pack: Object-oriented features (ES 203 790) | [All Projects] General | public | 01-10-2015 10:33 | 11-10-2018 14:20

Reporter | Jacob Wieland - Spirent |
Assigned To | Jacob Wieland - Spirent |
Priority | normal | Severity | major | Reproducibility | have not tried
Status | closed | Resolution | won't fix |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version |  | Fixed in Version |  |

Summary | 0007187: Allow null-value for all value variables with the same semantics as uninitialized.

Description

There are numerous (non-conform) test suites in existence that use the null value for data types like for component types, i.e. for checking whether a variable has been initialized (v == null) and for even explicitly uninitializing it after it already has been initialized.
Enforcing the standard-conform null-semantics in a tool (restricting it so it can only be used for component, default and address types) makes all these test suites not usable in these tools. Test suite maintainers do not want to spend the effort of rewriting their (sometimes very large) test suite to use isbound() for null checks and adding workarounds for modelling null-values (like adding additional variants to union types or wrapping in single-optional-field-record types) in another way. The newer tools thus have a lower acceptance than their older non-standard-conform versions, even if they offer workarounds.
Therefore, I think it should be allowed to use null as a special value that can be assigned to data-type variables and can be checked against in the same way as for component, default and address types (with the same semantics as for these). NOTES that maybe this is a bad practice could be added to the sections in question.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR7187.docx (536,463) 05-11-2015 14:03 http://oldforge.etsi.org/mantis/file_download.php?file_id=3367&type=bug CR7187v3.docx (276,073) 21-07-2016 11:22 http://oldforge.etsi.org/mantis/file_download.php?file_id=3430&type=bug

Issue History
Date Modified | Username | Field | Change
01-10-2015 10:33 | Jacob Wieland - Spirent | New Issue |
04-11-2015 13:59 | Gyorgy Rethy | Project | TTCN-3 Change Requests => Part 01: TTCN-3 Core Language
04-11-2015 21:49 | Jacob Wieland - Spirent | Note Added: 0013497 |
05-11-2015 09:16 | Jacob Wieland - Spirent | Assigned To | => Jacob Wieland - Spirent
05-11-2015 09:16 | Jacob Wieland - Spirent | Status | new => assigned
05-11-2015 14:03 | Jacob Wieland - Spirent | File Added: CR7187.docx |
05-11-2015 14:13 | Jacob Wieland - Spirent | Note Added: 0013502 |
05-11-2015 14:14 | Jacob Wieland - Spirent | Note Added: 0013503 |
05-11-2015 14:14 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Jens Grabowski
05-11-2015 14:14 | Jacob Wieland - Spirent | Status | assigned => confirmed
05-11-2015 15:11 | Gyorgy Rethy | Note Added: 0013504 |
05-11-2015 15:59 | Jacob Wieland - Spirent | Note Added: 0013509 |
11-12-2015 15:58 | Gyorgy Rethy | Product Version | => v4.8.1 (published 2016-07)
11-12-2015 15:58 | Gyorgy Rethy | Target Version | => v4.9.1(ongoing)
11-12-2015 15:59 | Gyorgy Rethy | Status | confirmed => assigned
11-12-2015 16:01 | Gyorgy Rethy | Note Added: 0013604 |
20-07-2016 13:39 | Jens Grabowski | Note Added: 0014007 |
20-07-2016 13:39 | Jens Grabowski | Assigned To | Jens Grabowski => Jacob Wieland - Spirent
21-07-2016 11:22 | Jacob Wieland - Spirent | File Added: CR7187v3.docx |
21-07-2016 11:22 | Jacob Wieland - Spirent | Note Added: 0014027 |
21-07-2016 11:22 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Tomas Urban
21-07-2016 11:22 | Jacob Wieland - Spirent | Status | assigned => confirmed
21-07-2016 15:20 | Tomas Urban | Note Added: 0014031 |
21-07-2016 15:21 | Tomas Urban | Note Edited: 0014031 | bug_revision_view_page.php?bugnote_id=14031#r308
21-07-2016 15:21 | Tomas Urban | Note Edited: 0014031 | bug_revision_view_page.php?bugnote_id=14031#r309
21-07-2016 15:22 | Tomas Urban | Note Edited: 0014031 | bug_revision_view_page.php?bugnote_id=14031#r310
21-07-2016 15:23 | Tomas Urban | Assigned To | Tomas Urban => Jacob Wieland - Spirent
21-07-2016 15:23 | Tomas Urban | Status | confirmed => assigned
17-08-2016 16:13 | Jacob Wieland - Spirent | Note Added: 0014136 |
17-11-2016 13:55 | Jens Grabowski | Note Added: 0014307 |
17-11-2016 13:55 | Jens Grabowski | Target Version | v4.9.1(ongoing) => Next version (to be defined)
04-09-2017 09:18 | Jens Grabowski | Project | Part 01: TTCN-3 Core Language => Ext Pack: Object-oriented features (ES 203 790)
04-09-2017 09:18 | Jens Grabowski | Category | New Feature => General
11-10-2018 11:57 | Jacob Wieland - Spirent | Note Added: 0015253 |
11-10-2018 14:20 | KristÃ³f Szabados | Note Added: 0015255 |
11-10-2018 14:20 | KristÃ³f Szabados | Status | assigned => closed
11-10-2018 14:20 | KristÃ³f Szabados | Resolution | open => won't fix

Notes

(0013497)
Jacob Wieland - Spirent
04-11-2015 21:49

Maybe this could be allowed with a modifier for variables/formal parameters/constants/module parameters:
var integer @nullable v := null;
This would clearly mark it as a property of the variable (not the content), similar to optional and omit (where omit also is not the content of the field, but a property of the field)
Use of null for assignment and comparison would be allowed only for nullable entities.
isvalue and ispresent should still be false when called for these and all operations except comparison with a null-object should cause an error.

(0013502)
Jacob Wieland - Spirent
05-11-2015 14:13

I have added a proposal that generalizes the already existing null-concept for component, default and address types to a concept named "nullable" where each variable, formal parameter and return clause can be declared nullable by adding a @nullable modifier.
component, default and address types are always nullable, otherwise, a data object is only nullable, if it is declared with this modifier.
nullable objects can contain the special value null (i.e. they can be initialized with it and can be compared for equality/inequality with it).
As for the already existing nullable types, all nullable objects which are initialized with null are considered bound and concrete value (i.e. isbound and isvalue return true).
With the proposal, no fields or elements of structured values can be nullable (except for those who are automatically nullable). It would allow easily augmenting the existing use-cases for such null-assignment/checks.
For future consideration:
- default implicit/explicit nullable attribute (similar to optional attribute) to allow all variable/parameters/return types implicitly to be declared as nullable.
- nullable modifier for type definitions
- nullable modifier for field declarations
- nullable modifier for record of element types

(0013503)
Jacob Wieland - Spirent
05-11-2015 14:14

please review

(0013504)
Gyorgy Rethy
05-11-2015 15:11

I can't remember any conclusion from the discussion yesterday. I think a proposal is yet premature.

(0013509)
Jacob Wieland - Spirent
05-11-2015 15:59

no, but I didn't think a proposal would hurt and the matter is too important to be shifted due to lack of proposal, so I added it as further base of discussion

(0013604)
Gyorgy Rethy
11-12-2015 16:01

I mean there was no agreement, if this is something we really want in the language.

(0014007)
Jens Grabowski
20-07-2016 13:39

STF agreement: Proposal accepted. Jacob will add a few examples and assign it back to Tomas for final proofreading.

(0014027)
Jacob Wieland - Spirent
21-07-2016 11:22

please review and resolve

(0014031)
Tomas Urban
21-07-2016 15:20 (edited on: 21-07-2016 15:22)

Result of STF discussion:
TTCN-3 should be brought closer to programming languages such as Java or C#. That means the following changes:
1. All types with exception of four primitive types (integer, float, boolean, verdicttype) and one constructive type (enumerated) shall be nullable, i.e. in addition to the current set of values, they will contain the specific value null. Exclusion is made for performance reason.
2. For the mentioned excluded types, a nullable alternative can be explicitly made nullable using the @nullable modifier if needed:
type integer @nullable NullableInt;
3. Values, field and templates of nullable types that don't have any value explicitly assigned to them are implicitly initialized with the null value. This is actually not different from the current situation - the null value is just a different name for the uninitialized state which will completely disappear for the nullable types. Only three types that are currently nullable (component, address, default) will behave differently, because null and uninitialized are distinct at the moment.
4. The isbound, ispresent, isvalue will yield false for the null value.
Benefits:
1. Passing null from one variable to another (currently not possible with uninitialized variables)
2. Possibility to "uninitialize" already initialized value by assigning null to it
3. Null check with == and != operators (currently unintuitive with the isbound function)
4. Greater similarity with Java, C# and in some extent with C and C++
Drawbacks:
Minor backwards incompatibility for component, default and address types. These types will lose one of its states (uninitialized) and the behaviour of the isbound, isvalue and ispresent functions will change for operands of these types. The loss of state is most likely not harmful as it could only remove potential errors (e.g. comparison of uninitialized variable would yield false instead of a runtime error). However, change in the predefined functions could have some impact. The STF assumes that this impact is very limited, but it should be found out how often these functions are used in combination with the operands of component, default and address types in real test suites.

(0014136)
Jacob Wieland - Spirent
17-08-2016 16:13

STF-discussion:
- introduce all types (except integer, float, boolean, enumerated, verdict) as implicitly nullable
- add modifier to declare subtype of non-nullable types to be nullable
- add attribute to declare 'implicit null' for a syntactic context meaning that all values living in this context will always have null instead of <uninitialized> (i.e. even if an uninitialized field is assigned to a field, the result will be null)
- define new term "complete" to signify that something is completely initialized with non-null, use that those places where now "completely initialized" is used
- require completeness in most cases where now "completely initialized" is required
- check whether "completely initialized" is still needed anywhere where complete is not wanted
- isvalue() returns true only for complete values
- isbound() returns true for "at least partially initialized" structures, so also for null

(0014307)
Jens Grabowski
17-11-2016 13:55

Shifted to 2017. To be discussed in the context of OO extensions.

(0015253)
Jacob Wieland - Spirent
11-10-2018 11:57

I think in light of the OO developments, we can close this as unnecessary.

(0015255)
KristÃ³f Szabados
11-10-2018 14:20

STF agreement: not needed.