BoundSpec Declarations

Frederick_Wright

I was looking at the Featurescript for the Hex Infill feature, am puzzles by several aspects of the following:

<div>// integer from 1 to 100, default 10 (used for %Infill)</div><div>export const INFILL_BOUNDS =</div><div>{</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "min" &nbsp; &nbsp; &nbsp; &nbsp;: 1,</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "max" &nbsp; &nbsp; &nbsp; &nbsp;: 100,</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; (unitless) &nbsp; : [1, 10, 100]</div><div>&nbsp; &nbsp; &nbsp; &nbsp; } as IntegerBoundSpec;</div><div><br></div><div>// parameter values (real numbers) in various document unit systems with defaults</div><div>export const HEX_BOUNDS =</div><div>{</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "min" &nbsp; &nbsp; &nbsp; &nbsp;: 1 * millimeter,</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "max" &nbsp; &nbsp; &nbsp; &nbsp;: 100 * millimeter,</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; (meter) &nbsp; &nbsp; &nbsp;: [0.0, 0.025, 500],</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; (centimeter) : 0.5,</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; (millimeter) : [1, 5, 100],</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; (inch) &nbsp; &nbsp; &nbsp; : .25,</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; (foot) &nbsp; &nbsp; &nbsp; : 0.015,</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; (yard) &nbsp; &nbsp; &nbsp; : 0.005</div><div>&nbsp; &nbsp; &nbsp; &nbsp; } as LengthBoundSpec;</div><div>&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;</div><div>//----------------- &nbsp; &nbsp; </div>

Does the line  "(unitless) : [1, 10, 100]" redundantly define the min/max, given that they're explicitly given on the two lines above?

Somewhat similarly, for the HEX_BOUNDS, the line "(meter) : [0.0, 0.025, 500]" seems to contradict the min/max given on the two preceeding lines. Is one range ignored in favor of the other? Does it depend on the document units?

Thanks for any clarification.

kevin_o_toole_1

In previous versions of FeatureScript, there used to be two different concepts: A UI min/max, which would control how dialogs "clamp" to values when out-of-bounds values were typed, and a FeatureScript min/max, which is the actual max/min value that the feature would accept before throwing a precondition failure.

About a year ago, we unified these concepts to get rid of the conceptual overhead to FS authors. Now, a bounds spec does not contain a separate "min" or "max" field. Rather, you just define one unit with three values (e.g. [1, 10, 100]), and optionally specify a single, default value for other units (so a user with metric units doesn't default to some crazy decimal expansion).

The reason you see the hex fill feature working with the old system is that FS always preserves old behaviors without breaking anything. The author of this feature would only need to convert to the new system if he manually upgrades his Standard Library import version (at which point he would see some errors reported on his outdated code). A more detailed description of our general upgrade process/philosophy is outlined here: https://forum.onshape.com/discussion/comment/27472#Comment_27472

kevin_o_toole_1

In previous versions of FeatureScript, there used to be two different concepts: A UI min/max, which would control how dialogs "clamp" to values when out-of-bounds values were typed, and a FeatureScript min/max, which is the actual max/min value that the feature would accept before throwing a precondition failure.

About a year ago, we unified these concepts to get rid of the conceptual overhead to FS authors. Now, a bounds spec does not contain a separate "min" or "max" field. Rather, you just define one unit with three values (e.g. [1, 10, 100]), and optionally specify a single, default value for other units (so a user with metric units doesn't default to some crazy decimal expansion).

The reason you see the hex fill feature working with the old system is that FS always preserves old behaviors without breaking anything. The author of this feature would only need to convert to the new system if he manually upgrades his Standard Library import version (at which point he would see some errors reported on his outdated code). A more detailed description of our general upgrade process/philosophy is outlined here: https://forum.onshape.com/discussion/comment/27472#Comment_27472

Frederick_Wright

Thank you, Kevin, for the swift and thorough answer. Much appreciated.