fix(data-access): refer to fam for threads, nuts

[rskew]

This way we can do _get_nut_height("M8")

Thanks for the useful library :smile_cat:

[JohK]

Hi,

you are welcome.

I haven't worked with the library for quite a while and can't remember the exact reason for the current implementation, but there was a specific reason for it. (And yes I hated it :) Please add some tests to the pull request that demonstrate that legacy code won't fail after this change.

Johk

[rskew]

Hey, I think this would be a breaking change for legacy code. For example, some code might use _get_nut_height("M8x30) which would no longer work. I completely understand if you don't want to merge any breaking changes to the interface. If so I'll leave this closed.

Re tests, I'm more than happy to add tests for the changed functionality, however I'm not sure what these tests would look like (I'm pretty new to OpenSCAD and haven't yet come across anything resembling a unit test framework). If you could advise how to structure these tests I would appreciate it.

[hannesweisbach]

This would definintely break legacy code.

I think it would be best to add accessor/lookup functions that are designed to take only a family (i.e. "M5", "M8", etc) instead of a bolt (i.e. "M8x30"), for convenience because the screw length does not matter for most data items, like nut height, key width, etc …

This can be easily implemented like so:

function get_nut_height(fam) = _get_fam(fam)[_NB_F_NUT_HEIGHT];

[JohK]

Hi,

hmm. The accessor functions were intended to be kind of "private", thus their name starting with "_". When writing this I actually never envisioned, that users would like to access the database themselves: I was adding all the functionality I needed as a module anyways.

1.) Can - whatever you need the database access for - be abstracted as a general module? Thus avoiding the need for "public" access functions? Please provide a patch for new modules if this is a case. :)

2.) Do you think there is a general interest in having "public" access functions? Properties where the family name is specific enough, should then be accessible through the family or bolt name. I don't know what string operations are available in OpenSCAD nowadays and how difficult this would be to implement. Anyone interested in taking the challenge?

Cheers JohK

[rskew]

My use-case involves positioning things along a shaft, and the nut height helps position things in a way that's parameterised by the screw family. To be honest, my design (both physical and code) are probably pretty bad, but I think there could be legitimate use-cases for nut height :)

For point 2.) I think the current (private) accessor functions provide this functionality. All the info about a screw/nut is available by the family. For getting e.g. the nut height from the bolt name, the accessors can be chained like _get_nut_height(_get_fam("M8x45")). To me this is a pretty clean solution, with the exception that the accessor functions are currently named as private functions.

[hannesweisbach]

1) Not really. I use them to avoid having hardcoded numbers in my OpenSCAD code. For example:

distance = x + nut_height("M5");
translate([distance, … ]) …

then I know 2 weeks later I wanted to move something by x and also make space for an M5 nut, for example. The alternative would be x + 4.4; So I know I want to move something by x and the magic number 4.4. I have to give the reason in a comment so I don't forget.

Second, I don't have to look up the actual dimensions of hardware in the internet, but describe them symbolically. I dont care about the actual dimension of an M5 nut ;)

The database is there. Why not use it? Reduce redundancy.

2) Let me play Advocatus Diaboli here: How many people would have to be interested, for it to count as "general"? ;) Kidding aside, at least one person felt this is missing feature and openened an issue. Most users would probably just move on to the next library …