Currently, Wrap is an object that can encapsulate all wrapping cases where one or several of the following happens:
signature changes
inputs are transformed
outputs are transformed (according to output of wrapped function only).
But this doesn't cover situations where the wrapped function call may need to be modified, or the output trans need to be controlled from the interface. For example:
wrapped function needs to be called in a subprocess
wrapped function needs to be "iterized" (i.e. we want to call it with map(func, ...) instead of just func(...)
output_trans is saving or logging the output and aspects of this (where it saves or logs) needs to be controlled from the outside
Following are some structural ideas for this extension of Wrap.
Currently,
Wrap
is an object that can encapsulate all wrapping cases where one or several of the following happens:But this doesn't cover situations where the wrapped function call may need to be modified, or the output trans need to be controlled from the interface. For example:
map(func, ...)
instead of justfunc(...)
Following are some structural ideas for this extension of
Wrap
.Sourcing from user input with
call_forgivingly
Repurpose ingress
Factory layer
can be written (or at least subsumed) by this:
If we add the following "factories layer" to that:
we get:
More direct alternative