-
Notifications
You must be signed in to change notification settings - Fork 1
Design notes
We've seen this in dol and starting too in i2.wrapper and meshed now.
We usually have multiple wrapper levels Russian-dolling each-other, which makes it hard to debug, doctor, and might even be inefficient.
If instead, we used something like the command pattern to accumulate wrapper commands in a list and iterated through the list to carry out the commands, would we make the world a better place?
def wrap(func, ...):
if isinstance(func, Wrap):
func._wrap_commands.append(new_wrap_command)
else:
# the normal way
...A fluid interface would look like this:
wrapper = mk_wrapper.name_map(a='x', b='y').defaults(x=10).reorder(('y', 'z'))and when go to wrap...
wrapper.wrap(func)we could go through the list of wrap commands and make the wrappers, or even combine several together when it's possible, which could lead to more efficient (and simple perhaps) code.
We'll have to decide where we want to place ourselves on the interpreter-compiler implementation spectrum.
- Why not do decorators "the normal way"?
- Make Frequent patterns easy (and correct)
- Build a components+combinators framework for wrappers
- Closures don't pickle
- The
Wrapclass - The
Ingressclass

The Ingress class offers a template for creating ingress classes.
Note that when writing a decorator with i2.wrapper, you're usually better off writing an ingress function for the purpose.
As a result, your code will usually be less complex, easier to read, and more efficient than using the Ingress class.
So why use the Ingress class at all? For one, because it'll take care of some common mechanics for you,
so once you understand how to use it, you'll probably create a correct wrapper faster.
Further, if you're writing a general wrapping tool (e.g. your own currying machine, some rule-based input casting function, etc.)
that needs to build wrappers according to some context-aware logic,
then you might find that using Ingress will help.
