Three Dollar Quill

Okay, traveled today, but I still want to try and do the work I had planned for MOTR, which was to...

Oh no.

It was to evaluate all of the ill-fitting names in the upper layers of the API and try to come up with better alternatives.

All right, let's work through these modules alphabetically...

• arguments.py: Rename to command_builder.py, see how it treats me from there. Could stick Builder on the end?
• command.py: Oof, not really sure. Also, this module contains one of the *Meta classes, which really need something nicer. I mean, maybe just renaming all of those classes to Metadata would help things?
• dynamic.py: Ooooof. Another *Meta, that one should just get whatever treatment the others get. The bigger puzzle is Dynamic itself. Like, Dynamic is a pretty questionable name for a concept in this context. What is it? Well, it combines a bunch of metadata with a function that has a particular signature; and this lets it... Um... ThisIsUsefulISwear. Okay, stepping back for a sec. The point is to call the function with every valid combination of parameters. So the various names involved should say something about parameters. Let's try and consider Dynamic, Objects, and Items together, and oof. Now, whatever Objects is, it's agnostic to all of this parameterization stuff, so it might deserve to get the Registry name back. Items can be ParameterRegistry if I don't think of something better. (And ItemLabel turns into ParameterLabel.) And Dynamic can change to Parametric, or something better. The helper methods should mention parametric. inject_into_parametric, map_1_over_parametric, map_2_over_parametric, NoParameters, no_parameters, reduce_parameterization...
• I can't tell whether the flex.py names are good or not, so let's put a pin in those...
• Something feels off with the input_accumulator.py stuff (like that the core type is accumulating specifically into a _cmd.PathStr, and using adaptors to make types of other values work with that, but I'm again not sure what to do differently.
• installer.py feels like maybe I want to divide it up. Before I changed the code to make the new tests... work... this module had much fewer classes in it.
• invocation.py is confounding because somehow I've written another command builder, and it doesn't replace the others, it just builds on them, with an interface that is "nicer" in some sense that I'm not sure how to quantify. I guess the point is that this bridges the command stuff and the dynamic/parametric stuff, like a kind of... ParametricCommand. That's definitely clearer, in that you can look at it and mentally break it down into the questions of "what does 'parametric' mean?" and "what is a 'command'?".
• items.py: the "Item-to-Parameter" change should handle all of this.
• objects.py: the "Objects-to-Registry" change should handle it.

Also, for those last two, and maybe some others, I want to roll the "use TypedMapping" change out so I don't have to worry about code drifting out of synch.

So, I'll think this over in the morning or next week, and see what I think. For now, I really want to wrap things up.

Good night.