You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As also pointed out by SonarCloud in a detailed analysis this PR introduces some code duplication. We'll accept these for now, to not get in the way of the 'merge train' leading up to the introduction of the Projects feature (it could complicate rebase of subsequent PRs in the queue) but this issue will serve as a reminder to revisit this once the strain stops at the next station.
To re-evaluate how much of an issues this still is, especially following changes in PR #1135 and the (expected) follow-up PR refining kinetic decay megacomplex.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been closed due to lack of recent activity. Please open a new issue if you're still encountering this problem. Thanks for your contributions!
As also pointed out by SonarCloud in a detailed analysis this PR introduces some code duplication. We'll accept these for now, to not get in the way of the 'merge train' leading up to the introduction of the Projects feature (it could complicate rebase of subsequent PRs in the queue) but this issue will serve as a reminder to revisit this once the strain stops at the next station.
As @s-weigand puts it:
For the sake of getting on with the "merge train" I guess this is fine from my side.
Even so, I don't agree with the removing of
DecayMegacomplexBase
which added useless code duplication and cyclic import workarounds, just because of a disagreement about using abstract base classesOriginally posted by @s-weigand in #860 (review)
The text was updated successfully, but these errors were encountered: