Any reason we can't use other punctuation in variable names?

Answers

• Options

  S1mon Member Posts: 2,359 PRO

  November 2021

  I don't know the true answer to this, but in general, writing parsers for computer languages is tricky if you add in things that could be interpreted as part of an equation. That said, some languages these days allow all kinds of emoji and goofiness in variable names, so perhaps there would be a way to put in some characters that look like what you want, but wouldn't be interpreted as math.

  0
• Options

  kevin_o_toole_1 Onshape Employees, Developers, HDM Posts: 565

  November 2021 edited November 2021

  When you need to reference a variable, you use it in an expression in a feature or sketch dimension like #myVariable/4 + 2 in
  
  If we allowed the variable "1/4-20", then a reference to it would look like #1/4-20 , which is ambiguous. Did you mean the variable "1" divided by 4 minus 20? or the variable "1/4" minus 20?
  
  Therefore, we are restrictive about what you can name variables. The first character can't be a number, and all characters must be numbers, letters, or _. These rules for "identifiers" (variable names) are pretty universal across a variety of programming languages with a wide variety of syntax.
  
  
  ----------------------
  
  Since this is the FeatureScript forum, I'll also mention how this works in FeatureScript:
  
  The variable feature is calling the setVariable(context, "varName", 1 * inch) function. References to variables like #myVariable/4 + 2 in are translated into the FeatureScript getVariable(context, "myVariable") / 4 + 2 * inch . You might notice that these underlying functions can take arbitrary names, including ones that don't fit our naming conventions. Using invalid names here is recommended ONLY if you have internal variables that the users of a feature should not see. These invalidly-named variables will NOT appear in the variable table, and can NOT be referenced in features or sketch dimensions with the "#myVariable" syntax. From the feature users perspective, they don't exist.
  
  So, you might develop the convention of naming internal feature variables starting with an illegal character like "@" (e.g. "@foo" instead of "foo"). That ensures features can access them with getVariable(context, "@foo"), but end users cannot see, use, or overwrite those values.
  
  

  6
• Options

  Evan_Reese Member Posts: 2,064 PRO

  November 2021

  Thanks for the rundown @kevin_o_toole_1
  I definitely get the ambiguity of the "1/4-20" example. It would still be really handy to me to be able to do "M1.6" which I don't see as having the same issue. I also get that it would be unconventional to allow a decimal point as compared to other languages, but maybe it makes sense for Featurescript to break that convention. Of course, I'm far from qualified to say for sure, but it would help me in this particular instance.
  
  I also didn't know that about the invalid names. So you could use that, for example, to create some features that are meant to be used in sequence and they could pass some data around without exposing it to the end user?

  Evan Reese / Principal and Industrial Designer with Ovyl
  Website: ovyl.io
  

  0