diff options
author | Vito Caputo <vcaputo@pengaru.com> | 2022-04-01 18:22:11 -0700 |
---|---|---|
committer | Vito Caputo <vcaputo@pengaru.com> | 2022-04-01 18:22:11 -0700 |
commit | 4351afc62b3dd1c7fb7f0bc563dae22ee0ec73d9 (patch) | |
tree | f604cb82ccf97d71ec4a6fede21c20eb9aa57e9b /m4 | |
parent | 6b8790a22c38e0d5419eb5a4dac5e30f684ae473 (diff) |
til_settings: make res_{desc,setting} optional
The til_settings_get_and_describe_value() helper (and the calling
setup methods in the modules) can be useful in independently
spitting out a baked setup instance from a fully resolved
til_settings_t which has already gone through the whole
rigamarole of getting populated and described.
Normally when this all happens in one place with the setup
instance then either immediately fed to create_context(), or
stowed somewhere for future use, it's not a problem to always
require the res_desc,res_setting parameters.
But especially in GUI scenarios (glimmer) the whole populate and
describe phase of til_settings_t can very easily be done in a
separate place from the convenient place to produce a setup out
of it. So when the caller /knows/ the setup is finished and a
subsequent call with the same til_settings_t would produce a
res_setup immediately, the caller should be able to omit
res_setting and res_desc as they're of no use now.
This is all kind of crufty, but it's nice to have all this
happening in a single setup method to help keep the res_setup
phase from diverging/becoming out of sync with the
populate+describe phase. Will live with it for now. Frontends
get written far less than modules, so the API cruft from the
frontend perspective is relatively benign. It's still relatively
sane and ergonomic from the module writer's perspective.
Diffstat (limited to 'm4')
0 files changed, 0 insertions, 0 deletions