Multiple thread starts about threadlib HOT 3 OPEN

Just a thought about this.
I think you could mitigate the concern around existing personal THREAD_TABLEs by using the len() function.

I havent looked at your code directly yet, but I presume you have a public API that is essentially parsing user input and then sending that to a private worker function to do the work on the thread params.

If true, then it seems like it would be pretty easy to extend your internal table to include the # starts column, and then when you go to pass that information back to the private function you first check if the number of starts is provided for that thread profile, else you default to 1. and possible kick off a warning.

pseudo code concept:

table = [ A, B, C, D ];
search for thread C profile.
profile = C // [ name, ..... , ... , ... , num starts ] or [ name, ..... , ... , ... ] if num starts is not specified.
num_starts = 1; // quick assignment to default value
if( len( profile ) == max_profile_len )
{
num_starts = profile[x];
}
private_function( ......... )

from threadlib.

I'd have to look into that. What makes life a bit nasty is that OpenSCAD apparently allows only a single statement inside a function. As far as I understand, you cannot lookup first, then decide.

The current code is this:

function thread_specs(designator, table=THREAD_TABLE) =
/* Returns thread specs of thread-type 'designator' as a vector of
[pitch, Rrotation, Dsupport, section_profile] */

table[search([designator], table, num_returns_per_match=1,
               index_col_num=0)[0]][1];

from threadlib.

I have not looked at the code, so I'm not sure this would work for functions ( Recall them not being very friendly .

I have seen either extenttion blocks at the end as well as version information. The version information is more future proof. It's too late to do that since you already have a structure, but - if you add the version as the last parameter, and you make it obvious ( v1 ), entry without it is assumed v1/v0.

There are two slippery slopes:

• It makes it too easy to pile on features, that maybe should not be there ( lets just make a new version )
• You may endue with "Dead Info" fields. unused in most cases, but you still need to deal with it.

Thinking about that last one - maybe the "version block" can contain some type of "structure" that describes the blocks ( thread+multi ) - but again, this is an increase in complexity.

from threadlib.