[espenbodal]

Closes #106. Adds resource_family(p::Resource), defaulting to typeof(p), and uses it in res_types and res_types_vec. No behaviour change for existing resources; see the issue for the motivation. Includes tests, NEWS entry and documentation.

[Copilot]

🟡 Changes recommended

The public API page references an unexported function without qualification, which can break documentation generation.

1 open finding

• Unqualified resource_family breaks Documenter docs build · New

What changed in this PR

Adds resource-family grouping so related resource types can share segmentation and resource-specific model hooks.

Changes:

• Adds resource_family and updates segmentation.
• Adds integration tests.
• Documents the extension API and release note.

File	Description
src/​structures/​resource.jl	Implements family-based segmentation.
test/​test_resource.jl	Tests grouping and model-hook invocation.
docs/​src/​library/​public/​resources.md	Adds API documentation.
docs/​src/​how-to/​extend-resource-functionality.md	Explains family extension usage.
NEWS.md	Records the new API.

🧠 Review effort: Balanced

---

Give feedback about Copilot approvals in this survey to enter a drawing for a $150 gift card.

[JulStraus]

See my comments. Note that the current module suggestion from Copilot is bullshit. That is not the structure we want to have. If a function is not exported, it is not in the external library, that is the simple rule.

Additional comment:
We are currently in a situation with additional variables that it always only create one set of variables per resource, even if it theoretically could get them from a higher hierarchy as we use it for Nodes, Links, or ExtensionData. Do we see a case where this is not sufficient?

I.e., for your example,

abstract type AbstractPotentialPower <: Resource end
struct PotentialPower <: AbstractPotentialPower
    # fields as above
end
struct BoundedPotentialPower <: AbstractPotentialPower
    # fields with different bounds
end

you can either create variables for PotentialPower and BoundedPotentialPower (if you do not add the new method) or AbstractPotentialPower. But never variables for PotentialPower and AbstractPotentialPower simultaneously. In this case, we must follow the approach used for, e.g., Node.

[JulStraus]

Looks good to me now. Please provide a proper squash message, i.e., do not use the Default one provided by GitHub as it includes all individual commit messages, including stuff which is entirely reversed.

Reference to the issue is neither required in the commit message, as it will include a reference to the PR, and hence, indirectly the reference to the issue.