nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Using Enumeration literals as values the right way

medini_1024169437

I recently was asked how to set failure rate mode of a "Failable" the right way. The attribute is of type FailureRateMode, but any attempt to set it failed, neither

element.failureRateMode = Metamodel.safetyModel.FailureRateMode.FROM_PARENT

nor

element.failureRateMode = "FROM_PARENT"

did work.

Well the reason behind is an obstacle in the way how Enumerations value are passed and represented in the Metamodle singleton (the EMF Enumerator basically). I don#t want to bore you with details but just tell the solution.

Whenever sou want to set an Enumeration value, you need to add ".instance" to it. So basically:

element.failureRateMode = Metamodel.safetyModel.FailureRateMode.FROM_PARENT.instance

should do the trick.

Happy Scripting

Jan

Find more posts tagged with

medini

medini legacy

Accepted answers

All comments

medini_1036016653

Beware, using

element.FailureRateMode = Metamodel.safetyModel.FailureRateMode.FROM_PARENT.instance

fails silently (no error!). The issue is a capital letter "F" of the element's property "failureRateMode".

medini_1024169437

Hello Peter,

Java Script is by default very "relaxed". Writing any undefined attribute is silently ignored.

You can change that behavior with some pragmas, please have a look at this article.

Happy Scripting

Jan

medini_1036016653

Dear Jan,

thank you for the hint. When I finde some time, I'll test, which of those pragmas would trigger on accessing/writing to undefined attributes.$STRICT_MODE$ sounds like a good candidate.

Kind regards

Peter

medini_1024169437

Its actually this:

// $STRICT_MODE$ $WARNING_AS_ERROR$

the first is to make the interpreter strict but that would issue just a warning, the second is to treat these kind of warnings as errors.

I usually have these two pragmas in all scripts I pass to the community.

Jan

medini_1024169437

Guys, I need your vote. As written its complicated or more precisely tricky to fix this "enumeration" issue.

We have multipel choices and none is really 100% nice to the script developers. So I would like to put all options on the table and ask you opinion:

Option: we fix all "Metamodel.XXX.Enum" by replacing it with "Metamodel.XXX.Enum.instance"
Option: we fix all setter and getter that accept an Enum.instance to accept / return Enum instead
Option: we just improve the setter to accept both, Enum and Enum.instance

Well, the first option is somehow obviously something we should have done in the beginning, so Metamodel.XXX.Enum return the "instance" of the Enum, (the Literal), not the "Definition of the Enum" as now. However there are two cons now:

Its not in line with the other stuff in Metamodel because you can access MM stuff an the ENum but not at the Literal
It will break all scripts that use Enum.instance

Option 2 is nicer to the developer because it may accept Enum but also Enum.instance. However, there would be still the problem that scripts get heavily disrupted for example any comparison "object.atribute != Enum.instance) will break

Option 3 is the smalle schange, it will just allw to either use Enum or Enum.instance when setting an attribute.No script is broken but still the developer has to use Enum.instance here and then.

So what's your opinion? If you have any question, don't hesitate to ask.

Happy Scripting

Jan

medini_1040753747

Is option 3 the winner?

medini_1024169437

Option 3 has indeed won the "competition" and was rolled out with 20.1 :-)

Jan