direct_api: Joint.connected_to is now a set(), not singleton

[ezrec]

• Make Joint.connected_to a set(), instead of a singleton

This permits multiple attachments to a single joint; for example a common 'origin' virtual mounting point; or multiple attachments to a slot in 2020 aluminum extrusion.

[codecov]

Codecov Report

Patch coverage: 100.00% and no project coverage change.

Comparison is base (8209624) 95.72% compared to head (f336813) 95.72%.

Additional details and impacted files

@@           Coverage Diff           @@
##              dev     #138   +/-   ##
=======================================
  Coverage   95.72%   95.72%           
=======================================
  Files          21       21           
  Lines        6455     6455           
=======================================
  Hits         6179     6179           
  Misses        276      276           

Files Changed	Coverage Δ
src/build123d/topology.py	95.52% <100.00%> (ø)

☔ View full report in Codecov by Sentry.

📢 Have feedback on the report? Share it here.

[gumyr]

Although I can see why this would be useful for linear joints like those on extrusions, it doesn't make sense to me generally. A ball and socket joint can't have two balls in the socket. Rigid joints would be confusing as two parts are likely to overlap.

Given that any part can have as many joints as desired, this seems like redundant functionality that just makes everything more difficult to understand. Is there a compelling reason by this approach is required?

[ezrec]

A ball and socket can't have two balls, but a ball can connect to two sockets (double-ball joint in claymation armatures) https://www.animationtoolkit.co.uk/12mm-double-ball-joint/

And with respect to Linear Rails, I'm working on a hardware library for my workflow, and it makes more sense to me to have a single linear joint for each side that I can attach multiple to, instead of having to instance with each specific rail with a unique joint set, ie something like:

class VSlot2020(Compound):
  def __init__(self, north_slot_joint_names = set(), south_slot_joint_name=set(), ....)
  ...
  
rail = VSlot2020(east_slot_joint_names = { "endstop", "carriage", "idler_block" })

[roman-dvorak]

I strongly support the proposal to allow multiple objects to be attached to a single joint, as it adds significant value and flexibility across various joint types:

1. LinearJoint: Essential for scenarios where multiple carriages need to move along a single linear guide. Splitting into multiple segments or using multiple linear joints is not sustainable, as it complicates object generation and maintenance. This approach would streamline designs and improve long-term manageability.

2. BallJoint: Simulating situations where multiple objects are suspended from a single point, akin to a "rope" attachment, is a practical application of this feature.

3. CylindricalJoint: Useful for scenarios such as a threaded rod with multiple independent nuts. While having two cylindrical joints on either side makes sense in some cases, the ability to have a single rod with multiple nuts is invaluable for other configurations.

4. RigidJoint: I suggest that attaching multiple elements to a single rigid joint simplifies complex assemblies. For instance, fixing both a thin part and a screw into the same joint can reduce the need for additional joints and simplify the design.

While this approach may introduce some inaccuracies in real things, it offers significant practical benefits for creating assemblies and similar tasks. I'm curious if this modification, from a single element to a set, necessitates changes in related areas such as assembly processing. Understanding the potential downstream impacts would be important for fully assessing this proposal.

Thank you for considering this enhancement.