Feat: general wrapper

[younesStrittmatter]

Description

a general wrapper that accepts arguments to field mappings as arguments

Type of change

• feat: A new feature

[benwandrew]

this is super cool! i hope John Ousterhout* would like the direction we're moving in ;)

one general question for my own understanding (which may be better for me to address in office hours): i'm confused about the relationship between the decorator/wrapper wrap_to_use_state in delta.py and this new wrap_to_use_state_general in wrapper.py. is the latter not ultimately replacing the former?

*reference to author of a book @hollandjg shared a while ago: https://milkov.tech/assets/psd.pdf

[hollandjg]

I like the look of this!

Would it be sensible to split up the wrapper into two – one which does the input name mapping, and one which does the output wrapping? Then we could use the two independently – perhaps your inner function needs to return two values (say conditions and experiment_js_code) and returns those as a Result/Delta object, but you still want a mapping. Conversely, perhaps you have a function which uses entirely standard naming for the variables, but you want to wrap the outputs.

[musslick]

Looks great; just got a minor comment for a name change.

[musslick]

Could the name be shorted, e.g., wrap_to_state? I imagine people will be using this a lot, so we might want to give it a short name.

[hollandjg]

hey @younesStrittmatter , do you think you could refactor this so that there's a wrapper function which just does the input field-name mapping? We could include that as an option in the on_state function from #33, but it needs to be an independent wrapper function first so that we can test it really extensively on its own.

[hollandjg]

I like the general idea of this a lot, and have included a lot of the ideas in #33. Would it be possible to make a simple wrapper function which just does the input-name mapping?

[hollandjg]

I think this is covered by the newest version of the state object – closing this now.