Three Dollar Quill

All right, after messing with other stuff all day, I am taking a closer look at the increasingly-ineptly-named CommandBuilder class, and I think I'm getting some ideas for how to go forward. (No, for whatever reason, I am not tired of this.)

The CommandBuilder has five fields, but the address a number of interlocking roles. First up, there's executable and partial_invocation, which are processed together to produce an InvocationEnvironment. Then, allowed_codes (which I recall is renamed in the future topic, but eh), pass_module_codes, and module_args.

There are a few things going on with those. One is that module_args is a Union, but I want to turn it into a constrained type variable. This would have some downstream effects that I haven't thought all the way through, but if I can put the distinction between "has module args" and "doesn't" into the type system, I want to. However, looking at these fields with fresh eyes, I see that pass_module_codes doesn't mean anything when module_args is None, so those fields should really be a single field that can contain a product type. Furthermore, the purpose of pass_module_codes is just to control the evolution of the allowed_codes variable, so it should be bundled together as well.

This works out to: ModuleInfo, CodeInfo, ExecutableAndInvocation, and...

And...

And...

I don't know! Somehow, using "command" in some capacity still seems to make sense, because this is the first level where it's looping back around to the scope of information in the task class, which is called Cmd. But keeping it feels like a copout. It's kind of like, these new names aren't great, they're fine, but not great, and bringing them together like this pushes them to the breaking point.

Well, I've thought about this for a long time now, and no luck. Maybe I need to just actually try it, either tomorrow or in a few days. For now, rest.

Good night.