Push farther on the K2 demo (which uses structs).
I ran into one significantly different requirement that structs surface which maps and other basic Data Model stuff didn't: in order to track "doneness" invariants across a whole structure, we need the final interation on the child NodeAssembler (meaning the call to either the "Assign*" or the "Done" methods, depending on whether *that* system was used recursively) to update the parent's state machine and let it know it's now correct for it to progress. (So far so good; *that* part is the same for basic maps and lists.) The trouble is... with maps, we could easily do this with one wrapper type; for structs, which may have different types per field, this is a lot less trivial! There's now a commentstorm in the 'map_K2_T2.go' file exploring alternatives for solving this. As usual, there are tradeoffs, and no single obviously correct choice. (E.g., the fastest, most inliner-friendly choice involves significant bloat to the generated code size and binary, so that one's certainly not a slam dunk.) Building a large enough prototype to disambiguate which of identified solution paths for this will perform best is of course a nice idea, but the volume of code that has to manifest to provide a sufficiently realistic benchmarkable prototype is... well, not looking feasible; we'll be better off doing a first draft of all codegen with a randomly chosen solution, and then trying variations from there. (Amusingly/headdeskingly, at some point I had it in my head that this call-up'ing situation was going to be one of the downsides unique to the alternate plans that kept the old builder interface plus "freezing" marks, and that this redesign jumped over it; alas, no, that was silly: both designs need this for similar reasons. (This design is still lighter in other ways, though.)) But! None of this is looking like show-stoppers, just Hard Choices. So, I'm going to table this -- and instead switch back to filling out the rest of the "ipldfree" next gen node kinds, and then, combined with the confidence we already have from those benchmarks in the previous few commits... start porting interface changes into core! (And just... assume everything will go according to plan when it's time to come back to this codegen stuff we're tabling here. If it doesn't... that'll be fun.) Oh! Also seen here: a slight improvement to the map assembler state machine tracking, now using an enum rather than bool. This is definitely a good idea and I'm going to lift it back to the other map implementations immediately, even if much of the rest of the poor 'map_K2_T2.go' file is sadly being left in a storm of todo's.
Showing
Please register or sign in to comment