Idea

Serge A suggested Mar 29 2017 at 9:47 AM Serge A edited Mar 31 2017 at 12:07 PM

Support optional (missing) values in Variant

This Flexscript code throws an exception, and the following appears in System Console:

exception: FlexScript exception: label notexists does not exist at /0 c: /testlink_instance i: /testlink_associated

There is no exception handling mechanism in Flexscript, and no way to see where the exception was thrown, which is a problem in itself for more complex models.

Even if there were an exception handling mechanism in Flexscript, dealing with missing values is such a common use case, that it deserves to be addressed.

Many statically typed languages moved towards using an optional type (Maybe in Haskell, std::optional in C++, java.util.Optional in Java). This type may contain just a single value or nothing, and usually offers means to check if it's empty or to obtain a value of the contained type in a safe way. For instance, in C++ it is possible to

- use optional<T> in conditional expressions (non empty values are evaluated as true)
- use optional<T>::value_or(default_value) to avoid exceptions

class Variant in Flexsim is supposed to support empty values already (if Variant::type equals VariantType::Null), but other objects don't seem to use this feature, and the public methods of the class don't allow to work productively with null variants.

The proposal is two-fold:

return null Variants rather than throwing an exception in LabelsArray::operator[], SubnodesArray::operator[]; or introduce a new safe element accessor (Variant& LabelsArray::get()) to avoid changing the signature of operator[].
extend the Variant class with methods which allow to check if it is empty or replace a missing value with a default value safely:
```
bool Variant::isnull() const;
Variant Variant::or(const Variant& defaultValue) const;
```

Variant::operator bool() should already work properly.

This is how how it may look for Flexscript users:

Implementation of this proposal would have minimal impact on the Flexscript language itself (no need to introduce new control flow structures). The Variant class needs only a couple of new public methods to support this feature. It would eliminate a huge source of exceptions which are not user-friendly (it's difficult to find the code which triggers them, it's impossible to handle exceptions in Flexscript). The new missing value idiom is consistent with the solutions developed for other languages, and encourages users to be explicit about how to handle missing values.

Old rank() and label() were already safe. New [] operator on .subnodes and .labels throws an exception, which interrupts the script and cannot be recovered from.

flexsim-optional-type-proposal-code.png (2.0 KiB)

flexsim-optional-type-proposal-newcode.png (7.1 KiB)

script.png (5.4 KiB)

2 Comments

Matthew Gillespie commented Mar 29 2017 at 10:07 PM Serge A edited Mar 31 2017 at 12:07 PM

For 17.0.4, labels["notexists"] will now return a null value and not throw an exception.

subnodes[3] will continue to throw an error it it doesn't exist since you should check the subnodes.length property before putting in an out of bounds value.

subnodes["notexists"] will continue to return a null value and not throw an exception as it did before.

· 3

Serge A commented · Mar 30 2017 at 7:58 AM

Good. Thank you. Would you also consider .or(default_value) method on Variant? That would help to have more declarative oneliners in the Flexsim GUI fields. Explicit if-else checks require custom code, which is not transparent to the GUI users.

This is an example from my reply to Mischa:

GUI users can see what data is provided by the oneliner. The oneliner is declarative and easy to reason about.

Custom code is opaque to the GUI users. A separate window has to be opened to read or change it. Reasoning about procedural code with a handful of local variables and conditional statements is more difficult for non-programmers.

This is also the reason to avoid exceptions in subnodes[3]. If a conditional statement is required for every node access, then users have to write custom code every time they want to access a subnode, GUI becomes much less useful.

0 ·

Phil BoBo ♦♦ Serge A commented · Mar 30 2017 at 3:47 PM

You can use the ternary operator ? : to do an if/else comparison in one line:

thing.subnodes.length > 2 ? thing.subnodes[3] : "baz"

A conditional statement isn't required for every node access. It is only required if there is a possibility that the node doesn't exist.

0 ·

Serge A Phil BoBo ♦♦ commented · Mar 31 2017 at 12:05 PM

> You can use the ternary operator ?

Technically, yes, the ternary operator is a solution, but it's a poor one for non-programmers, and a suboptimal one from the usability point of view.

Readability issues: It often leads to unnecessarily long expressions which have to repeat a subexpression:

(thing.subnodes.length >= 2 ? thing.subnodes[2] : otherthing).length >= 3 ? (thing.subnodes.length >= 2 ? thing.subnodes[2] : otherthing)[3] : "baz"
// instead of 
thing.subnodes[2].or(otherthing).subnodes[3].or("baz")

Longer expressions don't fit the narrow input fields of the GUI dialogs: it's harder to "read" what the model does, and it's harder to spot errors while writing. Condition is often many characters away from the subexpression where it matters. Nested ternary operators in a tiny input field are nearly impossible to decipher. All that pushes the users to use custom code almost every time.

Discoverability issues: Unless the user is already a C programmer (or knows a similar programming language), he or she may not know about the ternary operator. The auto-complete feature can suggest to use .or() method, thus any user can learn about it, but the ternary operator idiom relies on user's skills and discipline.

> A conditional statement isn't required for every node access. It is only required if there is a possibility that the node doesn't exist.

There's always a possibility that a node doesn't exist. If node access can throw exceptions, which cannot be handled by the user, checking subnodes.length every time is imperative.

Likely Scenario. A user creates a Process Flow and it uses .subnodes[3]. He or she runs the model, it works. Later the user changes something else in the model, and then suddenly sees this or similar message:

exception: FlexScript exception: label notexists does not exist at /0 c: /testlink_instance i: /testlink_associated

How the non-technical user can understand what went wrong and where? First, it looks like Flexsim itself is a buggy and unreliable software (it did work perfectly, and then for some cryptic internal reason it doesn't). Second, it may take hours, days, multiple phone calls, email exchanges etc to fix this problem. Third, when the user learns the hard way what the problem was and how much trouble it caused, he or she is likely to always check subnodes.length from now on or fall back to using rank() function.

0 ·

Mischa Spelt commented Mar 29 2017 at 10:05 AM Phil BoBo edited Mar 30 2017 at 3:45 PM

When using the dot notation, you can already do this:

var bad = model().notexists;  // Throws an exception
 
var maybeGood = model().notexists?; // Note the question mark
if( maybeGood != nullvar ) {
 // ... 
}

I am not sure what the ".labels" equivalent of this would be. Probably you can do something like call find on the labels node (if it exists).

· 2

Serge A commented · Mar 29 2017 at 1:09 PM

The point is I don't want the exception to be thrown, because it stops the entire script execution, the error message is not helpful, and there is no way to catch the exception. So the script will never get past the "var bad = model().notexists;" line.

Nice trick with the question mark, it's the direction I'd like Flexsim to be moving to; but it's not sufficiently generic. It doesn't work for labels with white space in their names, and doesn't work for SubnodesArray.

Having a one-line error-prone label/subnode/attribute access syntax is important, because oneliners are the default option everywhere throughout Flexsim interface, and writing scripts with conditional expressions is an "hidden" option for advanced users.

This is immediately readable:

This is not:

Right now the workaround is to use the old rank() and label() functions which don't throw exceptions:

I suppose .subnodes[3] and labels["notexists"] should behave similar to rank() and label() in this case.

1 ·

pflow-bad.png (5.3 KiB)

pflow-good.png (5.9 KiB)

script.png (5.4 KiB)

Phil BoBo ♦♦ Serge A commented · Mar 29 2017 at 4:35 PM

Yes, .subnodes["notexist"] and labels["notexists"] should behave similar to node() and label() in this case.

This is a bug. They shouldn't be throwing exceptions in this case. Thanks for pointing this out. I'll add a note to the dev list to fix this asap.

1 ·

Cookie preferences

Your privacy is important to us and so is an optimal experience. To help us customize information and build applications, we collect data about your use of this site.

May we collect and use your data?

Learn more about the Third Party Services we use and our Privacy Statement.

Are you sure you want a less customized experience?

We can access your data only if you select "yes" for the categories on the previous screen. This lets us tailor our marketing so that it's more relevant for you. You can change your settings at any time by visiting our privacy statement

Your experience. Your choice.

We care about your privacy. The data we collect helps us understand how you use our products, what information you might be interested in, and what we can improve to make your engagement with Autodesk more rewarding.

May we collect and use your data to tailor your experience?

Explore the benefits of a customized experience by managing your privacy settings for this site or visit our Privacy Statement to learn more about your options.

Idea

Support optional (missing) values in Variant

2 Comments

Things to know…

Your Opinion Counts

IDEA DETAILS

Related Ideas

Cookie preferences

Strictly necessary – required for our site to work and to provide services to you

Improve your experience – allows us to show you what is relevant to you

Customize your advertising – permits us to offer targeted advertising to you

Strictly necessary – required for our site to work and to provide services to you

Improve your experience – allows us to show you what is relevant to you

Customize your advertising – permits us to offer targeted advertising to you

Are you sure you want a less customized experience?

Your experience. Your choice.

Idea

Support optional (missing) values in Variant

2 Comments

Things to know…

Your Opinion Counts

IDEA DETAILS

Related Ideas

Cookie preferences

Strictly necessary – required for our site to work and to provide services to you

Improve your experience – allows us to show you what is relevant to you

Customize your advertising – permits us to offer targeted advertising to you

THIRD PARTY SERVICES

Strictly necessary – required for our site to work and to provide services to you

Improve your experience – allows us to show you what is relevant to you

Customize your advertising – permits us to offer targeted advertising to you

Are you sure you want a less customized experience?

Your experience. Your choice.