Optional ID structural refactor

[figueroa1395]

Implements #806 and continues the refactor started in #824. The scope of this PR is as follows:

• Remove hard-coded -1s in main_model_impl.hpp. 9810322
• Minor renaming. 56534a8
• Refactor check_components_independence. e7e734c
• Rename update_component overload for multiple components. 9cdb0d6
• Move and refactor independence related functionality to update.hpp. The rest of commits up until 2143cba address this.
• Final re-organize. cc76897

Out of scope:

• Move update_component out of main_model_impl.hpp.
• Reduce update_component overload number.
• Variadic template with V suffix.
• Homogenize CT, CompType and ComponentType.

[figueroa1395]

I just realized that check_id_na was supposed to be moved to dataset.hpp. I will address that on Monday, but besides that, everything else is ready.

[Jerry-Jinfeng-Guo]

you don't, that's my point. at some point, the scope is "large enough" and you should focus on what's currently already in scope. anything new that pops up can be moved to a follow-up (even if it's only minor). if there are no follow-ups: great

This is self contradictory statement.

[mgovers]

you don't, that's my point. at some point, the scope is "large enough" and you should focus on what's currently already in scope. anything new that pops up can be moved to a follow-up (even if it's only minor). if there are no follow-ups: great

This is self contradictory statement.

which part?

[Jerry-Jinfeng-Guo]

you don't, that's my point. at some point, the scope is "large enough" and you should focus on what's currently already in scope. anything new that pops up can be moved to a follow-up (even if it's only minor). if there are no follow-ups: great

This is self contradictory statement.

which part?

"anything new that pops up can be moved to a follow-up (even if it's only minor)" vs "if there are no follow-ups: great"
My original question is tied to this PR, not a theoretical question. You agreed to scope this PR, sure, no problem, on the condition the mentioned things will be addressed in a follow-up, which is the premise of the whole discussion.

[mgovers]

huge improvement. a couple remarks but nothing serious. feel free to resolve them

[figueroa1395]

c56adb2 Still not finished as now there are some memory leaks. Either it is something very "simple" I missed, or something very complex and then we may want a follow up to separate from this already large PR.

The issue may be related with independence_flags in main_model_impl.hpp.

[TonyXiang8787]

@mgovers, @figueroa1395, @Jerry-Jinfeng-Guo

I see the PR was initially green but after some commits it turns to red.

Maybe we can revert some refactors and merge this?

[mgovers]

@mgovers, @figueroa1395, @Jerry-Jinfeng-Guo

I see the PR was initially green but after some commits it turns to red.

Maybe we can revert some refactors and merge this?

i think so as well. it's very easy to revert the last 2 commits and then reapply in a new PR or cherry-pick the changes.

[Jerry-Jinfeng-Guo]

@mgovers, @figueroa1395, @Jerry-Jinfeng-Guo
I see the PR was initially green but after some commits it turns to red.
Maybe we can revert some refactors and merge this?

i think so as well. it's very easy to revert the last 2 commits and then reapply in a new PR or cherry-pick the changes.

Let's indeed make the additional commits a follow-up PR and merge this one for now.

[figueroa1395]

@mgovers, @figueroa1395, @Jerry-Jinfeng-Guo

I see the PR was initially green but after some commits it turns to red.

Maybe we can revert some refactors and merge this?

Reverted the last "problematic" commit. Will merge after CI passes and then open another PR.

[figueroa1395]

Merge only after #833 is merged, just for safety. That is why I added the do-not-merge label.

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
97.3% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud