Rant about parameter expression syntax

[m-egger]

Hello,

I've been using Houdini for close to two years now and in that time have gotten faily accomodated with the way the program behaves.

However, one thing that up to this day is hard to get used to is the way the parameter syntax is set up in regards to expressions. The thing I mean in particular is how you need backticks for expressions in String parameters, but not in any others. I know there is an explanation to this, but as an artist this confuses me as soon as I didn't write an expression for two days because it doesn't get into my head.

Just talking about intuitivity and learnability, I find that this just adds unneccessary confusion. I think somehow tweaking this would make all of Houdini just a tad nicer to work with, particularly in favour of those starting out with the program, as I know exactly that this issue was frustrating starting out. 

I just think it would make sense for expressions entered with a backtick to work in float parameters as well.

I realize this is a tiny tiny issue that I'm ranting about here, but I just had to let off some steam because I just sat here for 20 minutes wondering why my expression wouldn't work.

Cheers,

Martin

[hall]

Quote

I just think it would make sense for expressions entered with a backtick to work in float parameters as well.

I believe it follows the convention of many languages to handle string. It's very common in any scripting language to use single, double quotes to represent strings. in the case of the houdini backtick is an expression in hscript that does not represent a numerical value. If you represent everything with backticks, could be the same data type, what is not correct. Right? 

[MENOZ]

i think you SHOULD RFE to sidefx, they might come up with some clever idea to simplify or make it more accessible, you never know..

[acey195]

As I understand it, the backticks cast your value to a string. 
If you use backticks in a float field, it will be cast to a string and then interpreted again as a float;
Because it will only accept those kind of values, but this is basically casting your value twice, so there is a risk of losing data in some cases.

Since I'm one of those people of a "strongly-typed" persuasion, I kinda like how it is now
But for the stuff where strongly typed is less well suited, there is always Python you can use.
and you can also setup your default parameter language to Python as well.

[m-egger]

On 27.5.2018 at 11:52 AM, MENOZ said:

i think you SHOULD RFE to sidefx, they might come up with some clever idea to simplify or make it more accessible, you never know..

Already did - and it's filed. Just wanted to hear other people's opinions.

On 27.5.2018 at 2:27 PM, acey195 said:

As I understand it, the backticks cast your value to a string. 
If you use backticks in a float field, it will be cast to a string and then interpreted again as a float;
Because it will only accept those kind of values, but this is basically casting your value twice, so there is a risk of losing data in some cases.

Ohh! That is a very good explanation. Thank you for that!

On 27.5.2018 at 2:27 PM, acey195 said:

Since I'm one of those people of a "strongly-typed" persuasion, I kinda like how it is now
But for the stuff where strongly typed is less well suited, there is always Python you can use.
and you can also setup your default parameter language to Python as well.

Well, it's both that I'm talking about. Because AFAIK in string params you need to put Python in backticks as well?

And the point I was making was that it is a bitch to get used to when starting out. By now I don't really have an issue with it anymore, except the traumatizing memory of starting out with Houdini and failing to get expressions to work. 

[malexander]

The backticks remove the ambiguity of whether the string field represents a true string or an expression. There's no ambiguity in float and int fields because all the characters must be numeric (or numeric related). If you're not a fan of the backticks, you can key the string parameter, then toggle to expression mode by LMB clicking on the parm label, then entering the expression. Keying and switching to expression mode removes that ambiguity.