Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.

First time visiting? Here are some places to start:
  1. Looking for a certain topic? Check out the categories filter or use Search (upper right).
  2. Need support? Ask a question to our Community Support category.
  3. Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
  4. Be respectful, on topic and if you see a problem, Flag it.

If you would like to contact our Community Manager personally, feel free to send a private message or an email.

Featurescript language - testing non booleans?

traveler_hauptmantraveler_hauptman Member, OS Professional, Mentor, Developers Posts: 419 PRO
edited April 2016 in FeatureScript
This is not really a feature request because it depends a lot on the intent of the FS language designers.

It can be really useful if undefined tests as false and everything other non-boolean value tests true.

var result = maybe_do_something(); //Returns undefined if unable to do something
if(!result){/*Handle missing value*/}
It can be useful if && and || can take non-boolean operands.
myCondition && nonBooleanExpression();
approach1() || approach2();

Comments

  • kevin_o_toole_1kevin_o_toole_1 Onshape Employees, Developers, HDM Posts: 493
    edited April 2016
    Part of FeatureScript's philosophy is that we prefer explicitly intent over hidden behavior.

    if (result != undefined) {} makes it clear that result is not intended to be a boolean, and that undefined is the intended error state (someone looking at your code sees that immediately). In this specific case an equally worthwhile protocol can be to have maybe_do_something() throw an error in the empty case, and use try/catch, rather than an if statement, when calling it. This allows the function return and the result variable to be have checked types.

    myCondition : nonBooleanExpression() ? undefined makes it clear what the return value will be when myCondition fails.

    try { approach1(); } catch { approach2(); }  is certainly more more verbose than the boolean, but also makes it obvious when each statement gets run and what the result is in each case.
  • traveler_hauptmantraveler_hauptman Member, OS Professional, Mentor, Developers Posts: 419 PRO
    That's awesome and exactly the right thing for the standard library.

    For myself though, I'll be trying to bang out a quick bit of automation in featurescript a couple times a year and will have just been using who-knows-what language and idiom. I have done multi-week projects in C++, Ruby, Python, Bash, Javascript, and Java in the last six months and I forget the syntax details of every one when I put it down (except C :) ) .

    I've never been angry at a programming language for being too expressive or flexible.

  • john_f_carrjohn_f_carr Onshape Employees Posts: 74
    function truthy(boolean b) { return b; }
    function truthy(x) { return x != undefined; } /* or !(x is undefined), if that's what you mean */
  • traveler_hauptmantraveler_hauptman Member, OS Professional, Mentor, Developers Posts: 419 PRO
    In FS as it is, I think the type test is most readable.
    if ( result is undefined) { /*handle it*/}

    That doesn't make me want the shortcut any less though.

    Thinking about undefined reminds me how uneasy I get with returning undefined when a map key is missing. I always get stuck wondering if I need to differentiate, and test for, a missing key vs an existing key with a value of undefined. This trips me up everytime I touch Lua for instance where maps are such an integral part of the programming idiom. JS has the same behaviour but I don't use JS in a way that makes me confront this.

    ...now I'm trying to remember which languages treat the undefined/nil value as true. I know I've seen it in other places but can't find it now.

  • ilya_baranilya_baran Onshape Employees, Developers, HDM Posts: 992
    In FeatureScript, there is no difference between a missing key and a key with an undefined value: when you iterate over a map, the values are never (untagged) undefined.  To be precise, use "== undefined" instead of "is undefined" because "is undefined" will return true on undefined with a type tag.
    Ilya Baran \ Director, Architecture and FeatureScript \ Onshape Inc
  • traveler_hauptmantraveler_hauptman Member, OS Professional, Mentor, Developers Posts: 419 PRO
    edited April 2016
    I'm not following using == undefined vs is undefined. Under what conditions will they give different results?
  • ilya_baranilya_baran Onshape Employees, Developers, HDM Posts: 992
    It's a dark corner edge case -- if you (for some strange reason) decide to make a custom type tag that has undefined as a possible value (something we normally don't do).  In that case, x is undefined will return true, but x == undefined will return false because x has the type tag and undefined does not.  I don't expect this distinction to come up in real life.
    Ilya Baran \ Director, Architecture and FeatureScript \ Onshape Inc
  • traveler_hauptmantraveler_hauptman Member, OS Professional, Mentor, Developers Posts: 419 PRO
    Yes. Interesting. I haven't worked with type tagging a lot. I'll have to take a look.
Sign In or Register to comment.