Support for merged enum

[lolabeis]

Enumeration supports extension, where an extended enum adds enumerated values to a base enum. However those values have to be directly listed in the extended enum.

For reporting purposes, we would like the DSL to support extending an enum with the values of another enum rather than having to specify those values individually.

This applies in the CDM in the context of a rate option which can either be a floating rate (FloatingRateIndexEnum) or an inflation rate (InflationRateIndexEnum). For reporting purposes this may have to be reported as a single enum which is a merge of the two.

[lolabeis]

As part of this issue, we would also like the DSL to support asserting whether the value of a merged enum belongs to one or the other base enum - i.e. whether a rate option is a floating rate option or an inflation rate option in our use case - without having to assert against each possible value.

[SimonCockx]

In a way, I think this may be partially supported already.

This could be modelled with an empty super enum:

enum RateIndexEnum:

... from which FloatingRateIndexEnum and InflationRateIndexEnum can then extend:

enum FloatingRateIndexEnum extends RateIndexEnum:
	AED_EBOR_Reuters displayName "AED-EBOR-Reuters" <"Per 2006 ISDA Definitions or Annex to the 2000 ISDA Definitions, Section 7.1 Rate Options, as amended and supplemented through the date on which parties enter into the relevant transaction.">
	AED_EIBOR displayName "AED-EIBOR" <"Per 2021 ISDA Interest Rate Derivatives Definitions Floating Rate Matrix, as amended through the date on which parties enter into the relevant transaction.">
	...

enum InflationRateIndexEnum extends RateIndexEnum:
	AUD_CPI displayName "AUD-CPI" <"Australia: AUD - Non-revised Consumer Price Index (CPI)">
	AUS_CPI displayName "AUS-CPI" <"Austria: AUS - Non-revised Consumer Price Index (CPI)">
	...

A RateOption could then be modelled as

type RateOption:
    rateIndex RateIndexEnum (1..1)
    ...

There is a related issue that might sometimes lead to static compilation issues though: #531.

[SimonCockx]

As part of this issue, we would also like the DSL to support asserting whether the value of a merged enum belongs to one or the other base enum - i.e. whether a rate option is a floating rate option or an inflation rate option in our use case - without having to assert against each possible value.

We can potentially generalize this to have an operation that can assert whether a value is of some type, not just for enums. (much like Java's instanceof operator) Use cases include distinguishing between specific subtypes of a more general type.

On the other hand - we have also discussed introducing a concept such as dynamic dispatch for functions (much like how method overriding works in Java), or having a concept similar to Haskell's type classes (somewhat more extensible than dynamic dispatch). Taking this route might make the above operation superfluous.

Something worth discussing.

[hugohills-regnosys]

On the other hand - we have also discussed introducing a concept such as dynamic dispatch for functions (much like how method overriding works in Java)

Dynamic dispatch functions are discussed in issue #546

[hugohills-regnosys]

In a way, I think this may be partially supported already.

This could be modelled with an empty super enum:

enum RateIndexEnum:

... from which FloatingRateIndexEnum and InflationRateIndexEnum can then extend:

enum FloatingRateIndexEnum extends RateIndexEnum:
	AED_EBOR_Reuters displayName "AED-EBOR-Reuters" <"Per 2006 ISDA Definitions or Annex to the 2000 ISDA Definitions, Section 7.1 Rate Options, as amended and supplemented through the date on which parties enter into the relevant transaction.">
	AED_EIBOR displayName "AED-EIBOR" <"Per 2021 ISDA Interest Rate Derivatives Definitions Floating Rate Matrix, as amended through the date on which parties enter into the relevant transaction.">
	...

enum InflationRateIndexEnum extends RateIndexEnum:
	AUD_CPI displayName "AUD-CPI" <"Australia: AUD - Non-revised Consumer Price Index (CPI)">
	AUS_CPI displayName "AUS-CPI" <"Austria: AUS - Non-revised Consumer Price Index (CPI)">
	...

A RateOption could then be modelled as

type RateOption:
    rateIndex RateIndexEnum (1..1)
    ...

I think this is the correct solution. However it would require a significant amount of Java code generation work to implement because Rosetta enums are currently generated as native Java enums. This is a problem because Java enums do not support inheritance, so to implement this the Java code generation would need to generate an enum abstraction (e.g. wrap it in a class).

[hugohills-regnosys]

An interim solution which would be useful in other scenarios would be to provide a to-string and to-enum utility methods to enums, as described in #570

• The code InflationRateIndexEnum -> AUD_CPI to-string would result in a string "AUD-CPI" (uses the displayName if specified).
• The code "AUD-CPI" to-enum InflationRateIndexEnum would result in a enum InflationRateIndexEnum -> AUD_CPI.

A RateOption could then be modelled as string:

type RateOption:
    rateIndex string (1..1)
    ...