Coding 2023-01-26

Tags:
By Max Woerner Chase

All right, let's see where I want to take MOTR's artifact module. The key thing I realized thinking about the reorganization is that I can corral some functionality into the "constructor" idea I had, so it can be a helper class that, instead of unpacking all of that into an Output, it gets included into the class, and delegated to for the following flow:

So, what do I want to call this?

(Horrible diversion: there are legitimate reasons to try to retire the concept of the MapOverSelection and make this code work directly with Parametric[PathStr] objects, but oh boy I do not have the bandwidth for that currently.)

Actually, can I run with that parenthetical? It takes several Parametrics and, I want to say, it condenses them into one?

"Condense" is the word that my gut wants me to use, and I need to ponder what sense it has in this context. I think the reference is to the idea of condensing a piece of writing, and not directly to anything involving physical substances.

I guess what I'm wondering is, can I come up with a nicer name than Parametric? Aside from the classes that I'm actively attempting to remove in the current effort, Parametric seems like pretty low-hanging fruit. Its point now is that you give it a Box and it uses metadata to create Selections from that Box, and passes them in together to a function.

Slightly alarming idea: I've been looking at some of the code I've written, and wondering if using ContextVars would be a cleaner way to handle shared data/behavior.

A somewhat-related idea that occurs to me is that the implementations for, um, Parametric.instantiate, in some sense, "should" be written with the keys they access in their signatures somehow. Maybe something really straightforward like def instantiate(box_var: Annotated[int, SOME_BOX_INT_LABEL], selection_var: Annotated[str, SOME_SELECTION_STR_LABEL]) -> ResultType:.

I don't have a sense for whether these are unambiguously good ideas I'm tossing around; they do seem like they would improve some things, but I can't tell if there are any major caveats.

...

I took some time to trace the implications of what I want to change, and they're frankly too complicated. If I can convince myself that some invariants that the code currently maintains don't actually matter, then I can cut down on the number of classes used.

I think the play to make is, this weekend, put together the required changes to artifact, and try not to worry too hard about the names. Then, switch to the documentation branch and start documenting the invariants of the parametric, parametric_command, and artifact modules.

My suspicion is that those modules in particular are dragging around some outdated simplifying assumptions. If I can nail down what those modules need, I can work out the feasibility of cutting down on the number of high-level concepts in the code.

Independently of that, I also want to mess around with context variables a bit, because I think they can substitute for most but not all of the uses of a heavily-forked variant of the punq library I'm using in another hobby project.

I think that's all for now.

Good night.