Coding 2023-04-13
I was thinking about how to organize the new code in MOTR, and something occurred to me: That higher-order decorator is really squirrelly, and I'd rather leave it as a module implementation detail than something that gets exposed to other modules. Doing that requires pulling a bunch of code into the parametric module, which is... probably fine? The only real hurdle is that I'd need different names for the "fake value" classes. Again, probably fine. I can stick them inside the associated classes, even, probably.
Let's try that, actually... I mean, it didn't break yet, with the obvious caveat that I'm not really testing these paths.
If it's not broken yet, let's stuff more things in to see if it does...
Well, now all that's left is to figure out the proper way to handle the decorators for MappedParametric. That, and to write the validation for AdaptiveParametric. I should be able to handle that...
And, the validation should be done now. The big thing missing is the last constructor, and instead of rushing into that, I want to take some more time to consider whether to do this as top-level functions, or classmethods, or what.
Like, more cruft at the top level, versus longer access paths on decorators, and is that even the rate dimension to be comparing for tradeoffs...
Not something that I want to rush into.
For now, I'm going to get ready for bed.
Good night.