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

EvanReese

I'm trying to set up some variables for common hardware we have, and most of the item names contain things like "M1.2" or "1/4-20". I don't like using "M1_2" and "1_4_20" instead. Is there any chance of that becoming possible with a future update, or is it fundamentally a bad idea for some reason I can't see?

S1mon

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.

kevin_o_toole_1

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.

EvanReese

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?