Joint boilerplate

[chenkasirer]

Moved some stuff around the Joint classes to reduce some of the boilerplate coded needed to implement a new joint.
Added some unittests to validate joint creation.

What type of change is this?

• Bug fix in a backwards-compatible manner.
• New feature in a backwards-compatible manner.
• Breaking change: bug fix or new feature that involve incompatible API changes.
• Other (e.g. doc update, configuration, etc)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• I added a line to the CHANGELOG.md file in the Unreleased section under the most fitting heading (e.g. Added, Changed, Removed).
• I ran all tests on my computer and it's all green (i.e. invoke test).
• I ran lint on my computer and there are no errors (i.e. invoke lint).
• I added new functions/classes and made them available on a second-level import, e.g. compas_timber.datastructures.Beam.
• I have added tests that prove my fix is effective or that my feature works.
• I have added necessary documentation (if appropriate)

[obucklin]

You say it's a breaking change? what is going to break?

[chenkasirer]

You say it's a breaking change? what is going to break?

Breaking changes are anything that can potentially break code that's using the changed code. For example, change in function signatures (name, number and type of arguments, return value[s] etc.). Such changes are included in this PR.

In compas_timber I of course fixed the calls to the changed code, but theoretically there might be other code out there (e.g. not part of COMPAS Timber) that uses it as a library because COMPAS Timber is so awesome, and its authors should now check carefully what we change and change their code accordingly.

[obucklin]

I know what breaking changes are generally. ;-D Just not sure what would break here specifically. On 6. Mar 2024, at 09:42, Chen Kasirer ***@***.***> wrote: You say it's a breaking change? what is going to break? Breaking changes are anything that can potentially break code that's using the changed code. For example, change in function signatures (name, number and type of arguments, return value[s] etc.). Such changes are included in this PR. In compas_timber I of course fixed the calls to the changed code, but theoretically there might be other code out there (e.g. not part of COMPAS Timber) that uses it as a library because COMPAS Timber is so awesome, and its authors should now check carefully what we change and change their code accordingly. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because your review was requested.Message ID: ***@***.***>

[chenkasirer]

I know what breaking changes are generally. ;-D Just not sure what would break here specifically. On 6. Mar 2024, at 09:42, Chen Kasirer @.> wrote: You say it's a breaking change? what is going to break? Breaking changes are anything that can potentially break code that's using the changed code. For example, change in function signatures (name, number and type of arguments, return value[s] etc.). Such changes are included in this PR. In compas_timber I of course fixed the calls to the changed code, but theoretically there might be other code out there (e.g. not part of COMPAS Timber) that uses it as a library because COMPAS Timber is so awesome, and its authors should now check carefully what we change and change their code accordingly. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because your review was requested.Message ID: @.>

Ah lol, sorry about that.

Yea, usually these should be summarized nicely in the CHANGELOG.md but maybe I didn't do a great job writing it in enough details. I'll update it, but here's a more detailed summary:

• Removed attribute Joint.joint_type using the class name now where it was previously used.
• Joint.__init__() now takes a tuple containing the beams, it has to get them from the concrete Joint implementation.
• Removed argument cutoff from LMiterJoint as it was not used anywhere.
• Removed argument gap from TButtJoint as it was not used anywhere.
• Removed argument gap from FrenchRidgeLap as it was not used anywhere.