Three Dollar Quill

Instead of touching any code today, I'm going to try to fully lay out my thoughts on the general area I was talking about last time.

For context, I'm trying to rework the structure of the class that will be call artifact.Output once I've renamed everything. The various classes in the artifact module are (okay, fine, will be) implementations of the Artifact protocol, which defines a method that takes a callback which converts some value to a Parametric[command.Metadata] (or something along those lines. artifact.Output currently has provisions to inject other values in specific circumstances, which end up making it hard for me to determine which intermediate values are "supposed to" be used at various stages.

Now, I was thinking of putting together something really elaborate to replace this system, but I think the specific really elaborate thing I had in mind had its own problems. So, let's take it slow...

• The current system is required to work with pathlike objects for the "accumulation" phase that happens before anything else. It also has an optional "mapping" step that's required to stay pathlike, and could in theory be removed, so eh.
• Once the final pathlike is produced from the accumulation, an additional mapping step is carried out, and the relevant "PCM" object is constructed using the callback.
• The instance may contain information relevant to adding information about the parent path of the "final" pathlike to the "PCM", and if so, that pathlike is passed in. The mapped value cannot be used, because its type is not statically known.
• This could all be drastically simplified and address some of the problems, except for the case currently referred to as Extra (which will be Implicit). The callback passed in that case accepts a type that partially overlaps with MOTR's definition of pathlike, and we really want to be able to use the types outside of that overlap. While the type in question sometimes does contain path information, at least sort of, it's not guaranteed.

So, going from there... I don't think there's a sensible definition of "parent" for these "Token" objects, but unless I can formalize the types in question, I need the code to do something when this overlap happens, and I'd rather not stick isinstance checks in there.

So, I want to change this code both from a usage perspective, and from an implementation perspective. From a usage perspective, I want the "final" accumulated value to be what is passed to the command if possible (so, ideally not Extra/Implicit), and I want the other values to be Extra/Implicit.

This actually really helps, because it gets me that these extra values are only expected when the produced value is known to be pathlike. So, if there are update methods that restrict their validity based on the type parameter, then those methods are allowed to use the fact that the data is pathlike. I don't know if I should exercise that option, but it's there.

Anyway, a few other notes:

• Only the "explicit" value needs to be named, because the names will always sort of refer to the same things.
• However, it would be good to allow any output to have its own label.

These involve maps like PathLike -> T_co and T_co -> Datum, but the latter is only expected with T_co == PathLike.

Something else I need to keep in mind is that I believe I want to add these capabilities to the OutputFromInput class, which... hm... Basically, all of this logic "should" be neatly encapsulated somewhere, and the question of how to do that feels like maybe it should wait for after I've done the previous rounds of rewrites.

So, the plan for the coming days: take my existing plans, convert them into TODO comments in the code, then grind through them and take notes on what to do differently.

For now, though, I really need to sleep.

Good night.