Three Dollar Quill

I got distracted, so this is late again. Let's have a look at some minor tweaks to parameters.

I want to remove some of the repetition of the module names in the class and function names. Now, that could also bleed out into renaming the alias, because it's currently a little Pokémon-speak-y. (Granted, that isn't stopping me in most places, so it's not a high priority.)

Let's have a look at the generate_parameters function, though. That takes a set of labels, a, let's call it constants for now, and optionally a set of parameters to augment. The result is an iterator over a set of updated parameters objects.

I don't think there's another meaningful way to iterate over parameters objects, so the current way the name works is

fine.

But I wonder if there's a more explicit way to describe what it does.

Like the point is, you pass in a set of labels to iterate over, the constants to draw the values from, and an existing set of selected variables...

In some sense the point of all of these data structures is that they represent selections out of multiple possible values. So, what if we had select.Label, select.Labels, select.Selections, select.SELECTIONS, and select.select? I'll let those ideas stand for now, and move on to other things for the moment.

On the registry/constants side of things, the big change I'd make would be to re-export Label to provide a module interface that's consistent with parameters/select/whatever.

Next up: whether to make any big changes to flex. I feel like it does need some changes, but I'm not sure what those changes look like. One thing of note is that it's not a run-time dependency of parametric, so it's free to draw in many other dependencies...

• validators
• command
• input_accumulator
• installer
• parametric
• cmd
• mkdir
• parameters/variables/select/whatever
• registry/constants/whatever
• facts (requirements)
• io

Let's ignore cmd, mkdir, facts, and io off the bat, because they're in more core positions. It's a bit much to go into the remainder of those, so let's focus on flex. The basic purpose of the flex classes is to interact with the parameters/variables/select systems to make sure that a given output file is specified once per command and is different for each set of selections used to generate a command, and that related inputs can be passed multiple times to a single command if desired. There are two main classes there, and a bunch of auxiliary classes. Let's see what's needed to instantiate these main classes:

• FlexOut needs:
  • a "PathStrAccumulator, which is basically a way to take a base path, and update it according to a value derived from a selection.
  • a mapping function that takes the final path from the above and converts it to the desired type.
  • a parametric that produces the output names; this field is both poorly named, and should be made optional.
  • the label corresponding to the FlexIn that gets created; the caller is currently responsible for creating this, but should not be.
  • The helper for potentially requiring a parent directory to exist; this has to go somewhere, and I'm ambivalent about its current status.
• FlexIn needs:
  • a parametric that produces an Input wrapped around the ultimately-desired type.
  • an ordered collection of ValueAdaptors, which are what's responsible for deriving Paths from selections to pass into the accumulator mentioned above.
  • An additional field that I don't think callers are supposed to care about. Since FlexIn objects don't seem to be instantiated outside of the flex module, this seems like a safe assumption.

This stuff is all kind of named after how it behaves in the context of multiple configurations. It's "flexible" because you can define a command-line argument once, and it will automatically adjust to the pool of parameters it's supposed to select from.

As such, this is a bad name, because what most people will care about is how it behaves in the context of a single configuration. In a single configuration, these classes need to be produced or obtained in various ways to pass into helper functions that create a Part for a parametric command.

I'm going to have to think about this. For now, it's late.

Good night.