Remove boilerplate and duplication in controller setting definition #13920
Conversation
acolombier
force-pushed
the
feat/refactor-controller-setting
branch
from
172c8df to
d4182ef
Compare
acolombier
force-pushed
the
feat/refactor-controller-setting
branch
from
d4182ef to
e6dbe5b
Compare
| doc.setContent(QString(kValidBoolean).arg("false").toLatin1()); | ||
| { | ||
| doc.setContent(QString(kValidBoolean).arg("false").toLatin1()); |
There was a problem hiding this comment.
Was the removal of the heap allocation performance-motivated? If so I think there is a lot more we can improve here. Would you like some suggestions for that?
There was a problem hiding this comment.
Not really performance motivated since those tests are already sufficiently performant IMO (the whole suite run in ~1s on my machine), this is only because there was no need for it to be dynamically allocated
There was a problem hiding this comment.
Would you be okay to submit a commit to improve the tests?
| void reset() override { | ||
| m_editedValue = m_defaultValue; | ||
| emit valueReset(); | ||
| } | ||
|
|
There was a problem hiding this comment.
I think there are some more members we could try to implement conditionally. For example we could automatically implement stringify if the underlying type supports that (using C++20 concepts of SFINAE). Same goes for value(). Wdyt?
There was a problem hiding this comment.
Sounds like a great idea, although I wouldn't know how to do it. Would you be interested in submitting a commit to address that?
| using LegacyControllerSettingBase<SettingType>::m_savedValue; | ||
| using LegacyControllerSettingBase<SettingType>::m_defaultValue; | ||
| using LegacyControllerSettingBase<SettingType>::m_editedValue; | ||
| using LegacyControllerSettingBase<SettingType>::save; | ||
| using LegacyControllerSettingBase<SettingType>::reset; | ||
| using LegacyControllerSettingBase<SettingType>::connect; | ||
| using LegacyControllerSettingBase<SettingType>::changed; |
There was a problem hiding this comment.
can you explain why this is needed? The member functions should already be public while the member variables shouldn't be.
There was a problem hiding this comment.
Without this, I get error: ‘m_...’ was not declared in this scope
I believe this has to do with the multiple inheritance but I'm not quite sure tbh. Any better fix for that?
As discussed in #13669, this PR introduced a refactor of the setting definition with a generic to remove code duplication and the needed boilerplate when introduced new setting type.