Refactor get/set/del/hasSetting #2048
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rev: crash rev: domoticz rev: encoder rev: loopdelay rev: hass rev: i2c rev2: hass rev: mqtt rev: rfm69 rev: relay rev: rpn rev: settings setup rev: hb settings rev: telnet preprocessor fix rev: settings wrap rev: tspk bool style rev: wifi types rev: util hb rev: settings fixup! rev: settings
|
It feels like migrate configuration block needs to go completely. It is easier to track settings recording per-module instead of per-board and it will manage defaults without having each board duplicate getSetting({blah, index}, _default(index)) Also added wifi management without overwriting settings: |
mcspr
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
...Setting(key, index, default)->...Setting({key, index}, default)via helper struct. Normal...Settingwithout index works the sameconst char*.boolis no longer.toInt() == 1, butgetSetting("key", false).getSetting("key")does not specialize.The general idea for this approach is to have conversion functions specialised in a single place.
Migrate part is still a tricky one, since modules will know better about which types of settings are used and which ones are not. Keeping in mind that defines are still there, module itself can generate current configuration and provide it to user, so it is not required to overwrite any settings like that.
Latest update also adds conversion template struct override to provide custom conversion functions.
One way is to specialise existing
settings_convert_tbased onsettings_internals.hexamples. Another one is to provide a second argument togetSetting<..., TConvert>template. Not sure that the last option is strictly needed right now, but I wonder if some special conversions can be covered by that. For example, wifi sleep or secure client settings.