In some (entirely predictable) circumstances, I'm not up for serious work right now, but some stuff is occurring to me about MOTR.
I was talking earlier about creating Flex types to rearrange the overall flow of the Invocation processing. Well, here's something from earlier that I just remembered. While arguments and environment variables can be handled somewhat reasonably, "extra" inputs and outputs are just different enough that I think that I need to parameterize the Flex types.
But, if I go down that road, I'm going to need to be really careful.
Because, let's see...
The whole reason that "extra" inputs and outputs need this additional flexibility is that the coverage flow needs to support deletes.
Now, think this through...
The coverage erase command needs to be invoked together with the coverage run commands so they get the exact same set of flex arguments. I forget what order I thought things should go in, but this kind of seem like maybe the output-focused Flex objects need an adaptor function to handle their type parameter, while the input versions can just use the parameter directly.
I think that's about as much design work as I can handle for tonight, so I'm going to wrap up and take the rest of the night easy.