Skip to content

[Collision.Geometry] Use StateAccessor and Topology accessor#5908

Open
alxbilger wants to merge 7 commits intosofa-framework:masterfrom
alxbilger:useaccessors
Open

[Collision.Geometry] Use StateAccessor and Topology accessor#5908
alxbilger wants to merge 7 commits intosofa-framework:masterfrom
alxbilger:useaccessors

Conversation

@alxbilger
Copy link
Contributor

@alxbilger alxbilger commented Jan 29, 2026

This is to factorize the behavior, have the same common variables and expose the links.

[with-all-tests]


By submitting this pull request, I acknowledge that
I have read, understand, and agree SOFA Developer Certificate of Origin (DCO).


Reviewers will merge this pull-request only if

  • it builds with SUCCESS for all platforms on the CI.
  • it does not generate new warnings.
  • it does not generate new unit test failures.
  • it does not generate new scene test failures.
  • it does not break API compatibility.
  • it is more than 1 week old (or has fast-merge label).

@alxbilger alxbilger added pr: status to review To notify reviewers to review this pull-request pr: clean Cleaning the code labels Jan 29, 2026
@alxbilger
Copy link
Contributor Author

[ci-build][with-all-tests]

d_componentState.setValue(sofa::core::objectmodel::ComponentState::Valid);
if (!this->isComponentStateInvalid())
{
this->validateMState();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

validateMState() doesn't set the component state to be valid when the mstate exists. We either must change tje validateMSatet method or add a component state modification here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does it have to be valid? The only useful information is knowing if the state is invalid or not, but the validity is not important. Specially because this class in designed to be a base class. In this case, we don't have any rule to set the state to valid. The most illustrative example is BaseObject::init.

Copy link
Contributor

@bakpaul bakpaul Feb 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because it was the case before. Your PR is changing this component and fully rely on derived class to set the valid state.

IMO, we shouldn't expect only the derived class to set valid when it is finally the case, it is too difficult to maintain, we never know if a class is a 'real' leaf or not. With this design we can endup having object that are totally fine, all check passed, but because the last class didn't actually validate it, the object is in an invalid state. What I would advocate for is that all class set to valid as long as its test passes. And let the following class invalidate the state if necessary. This way no matter what is the class place in the inheritance tree, we know that the component state will always be defined.

But maybe this is more a meta question ?

@fredroy
Copy link
Contributor

fredroy commented Feb 4, 2026

Build OK. FIXME: 212 units, 447 scenes, 80 regressions 🤕

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

pr: clean Cleaning the code pr: status to review To notify reviewers to review this pull-request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants