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

ID | Project | Category | View Status | Date Submitted | Last Update
0007864 | Ext Pack: Object-oriented features (ES 203 790) | [All Projects] General | public | 26-08-2019 14:28 | 14-08-2020 11:15

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

Summary | 0007864: Allow overloading for object methods.

Description

Since most object-oriented languages allow at least parameter-side overloading of methods (i.e. methods of the same name with different parameter lists in the same class), this should be allowed in some fashion also for TTCN-3 classes.
To allow this, it needs to be possible to distinguish which version of the invoked overloaded method is to be called statically by analyzing the given actual parameters or to report that the invocation is ambiguous as at least two versions both match the actual parameter list.
To make two overloaded versions of a function of the same name distinguishable, one of the following criteria must be fulfilled:
- the set of mandatory formal parameter names of one version shall not be contained in the set of formal parameter names of the other version
- otherwise, for at least one mandatory parameter of one version the type of that parameter must be incompatible with the type of the formal parameter of the same name in the other version.
- otherwise, for at least one mandatory formal parameter of the version with the lesser number of formal parameters, the type of the formal parameter is incompatible with the type of the formal parameter at the same position in the other version.
This criterion is chosen to be robust against the later addition of new optional parameters. In the worst case, adding a new parameter to one version of an overloaded function shall render the calls of the other version ambiguous, but it shall not change their semantics to calls of the changed version.
I have also chosen the restrictions in such a way that in future versions, adding some less restrictive overloading that allows best-type-match overload-resolution as it is done in other object-oriented languages should still be possible.
EXAMPLE:
type class external StringBuilder {
// overloading by using different parameter names:
function append(charstring p_charstring) return StringBuilder;
function append(universal charstring p_ucharstring) return StringBuilder;
// overloading by using incompatible types for
// the same parameter name/position
function append(integer p_num) return StringBuilder;
function append(float p_num) return StringBuilder;
}
var StringBuilder sb := StringBuilder.create();
sb.append("foobar"); // ambiguous, can't be distinguished by type
sb.append(p_charstring := "foobar"); // unambiguous by name
sb.append(3); // unambiguous by type, can't be distinguished by parameter name

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files |

Issue History
Date Modified | Username | Field | Change
26-08-2019 14:28 | Jacob Wieland - Spirent | New Issue |
27-08-2019 08:34 | KristÃ³f Szabados | Note Added: 0015463 |
27-08-2019 15:05 | Jacob Wieland - Spirent | Note Added: 0015478 |
27-08-2019 15:05 | Jacob Wieland - Spirent | Assigned To | => Jens Grabowski
27-08-2019 15:05 | Jacob Wieland - Spirent | Status | new => assigned
14-08-2020 11:15 | Jens Grabowski | Note Added: 0015749 |
14-08-2020 11:15 | Jens Grabowski | Status | assigned => closed
14-08-2020 11:15 | Jens Grabowski | Resolution | open => won't fix

Notes

(0015463)
KristÃ³f Szabados
27-08-2019 08:34

please note that, just beacuse something is done by others it does not mean we also need to do the same.
It is important to note, that overloading can always leed to confusion (as of using the same name), that will make it more costly to develop and maintain.
Please keep in mind that this will also make checking the code slower, since you will no longer be able to assume there is only one function with a name.

(0015478)
Jacob Wieland - Spirent
27-08-2019 15:05

STF-discussion: we mostly agree with the above observations. So, we will not implement it for now.

(0015749)
Jens Grabowski
14-08-2020 11:15

The discussion on this proposal will not be continued.