Three Dollar Quill

Guess what time it is again!

That's right, it's time to try to come up with a name for a concept that I just discovered a few hours ago, and have yet to properly articulate!

So, I'm right now trying to increase the prominence of "Boxes" in MOTR's higher-level code. Like, you call a function, you get back a box, you can stick them together, maybe I write a helper for that to complain if you try to reuse a label, it's all good.

And when I was working on this, I realized that at one point in client code, the user is expected to construct Matrix objects from Command objects, but in order to actually get those matrices to generate Fact objects, it's sometimes necessary to augment the basic Box (constructed by other helper functions) with additional assignments, using information contained in a python_helpers.EntryInstaller that is next to the Command. When this is required depends on the nature of the Command object that was used for each Matrix. This means that there are these implicit connections that I once again want to make explicit.

I want to create an object that contains the Command and the EntryInstaller. I know this would go in python_helpers, and I have a decent idea of what the constructor should look like. The goal here is to provide easy access to the parts, for wrapper code, and to provide decent idioms and helper functions for client code.

Naming, though...

One important thing to note is that one of the module-level variables which, in only these five instances, I intend to replace, has a different name than the others. This represents different type parameters, and should be reflected in the variable name of the new object...

With that in mind, I think I could get away with the very on-the-nose InstallerAndCommand.

Anyway, I'm not committing to this until I've had some sleep.

Good night.