Exactly, an admirable goal to which adding the option to set default type hint would help greatly
If I may weigh in, as I kinda fit in all groups of users.
What about leave the hints as they are, making a checkbox somewhere to keep the set hint as default and put it somewhere inside guid-named xml file in an undisclosed location? Reading the setting upon launch of Grasshopper, to reduce slowdown in performance. Respectively if you set a new default hint a Rhino restart to be required.
As for the part of me that is still quite noobish in programming. How difficult would it be, or how much slowdown in performance could be expected, if you using reflection and (for the most inexperienced) set the type depending on whatever comes in with the wire? Another check box somewhere in the menu, a “Noob mode” if you will?
We will probably go with something in this direction after all. A per-component default Hint, that can be saved and loaded. This way, I think we will cover more ground with less confusion.
This might not be necessary, we will see.
This has a lot of “what ifs” associated with it. What if some numbers are ints, some are floats? What if some text looks like number (but is still text)? This might be a playground for some users who want to write some special-purpose plug-in, but generally I think that the user can just demonstrate
design intention and pick the right Hint. It’s not that bad.
I doubt noobs will try to implement “special” stuff.
As for the “what ifs”. To me an integer is an integer if you pass 1 from a panel then it’s “1” and it should be considered as a string.
That’s mathematically an integer but type-wise it’s a float. For Grasshopper. “Rounding” affects the rounding, not the type. I am not sure why it was chosen this way, but such is @DavidRutten’s design.
Yes, but not everyone would agree I think. Especially the “noob” you wish to help. If you pick the right Hint, it will be just converted to the right type and passed to you in the right form. For the computation-time savvy guys: this costs in terms of computation if the conversion happens, if it doesn’t need to happen, then it’s just a quick type check.
That would disregard a widely used precedent, since panel values are treated as numbers when used as inputs to most standard components.
We’re talking about GhPython only @Joseph_Oster.
I’m not, and I’ve followed this thread from the beginning, thank you very much.
The thing is “noobs” rarely change the Type Hint of GhPython, if it has to be adjusted for them without thinking about it they hook up a wire to GhPython and don’t ever consider changing the type hint. Then there has to be some rules these users must follow.
“1” is a string - is one of those supposed rules.
Also there are, even now, issues that arise from using numbers passed directly from panel. This is something that is mentioned in many tutorials and courses. One should use number slider, digital scroller, etc. or must pass the wire through one of these:
If the proposed “noob mode” is unchecked pass whatever you like and be sure to set the proper Type Hint.