We should get rid of UndoBlock's _paramsArray

[everyday847]

Leaving aside the larger question of how caching should be handled, I can say for sure this particular architecture isn't the right way to go. In the status quo, we have a _paramsArray that holds onto very disparate data. For each parameter, it holds two lists, depending on whether we are permitting pseudoknots in folding. It's not exactly clear whether this is necessary -- it's sort of futureproofing -- but there are (bad, perhaps architectural code smell) reasons why it makes sense.

Point is, there is zero benefit to having the _paramsArray rather than separately tracking a number of different values across these states. I am very confident about this. The reason is that the _paramsArray has to be typed very generously: it used to be any and I was able to narrow it to number | number[] | null. This is pretty horrible! You may agree that there is no relationship between "the number of GC pairs" and "A BITMAP OF THE DOTPLOT" -- why are they the same sum type

It also requires a ton of brutal type casts. If you set NUM_GC to a number[], it would just forgive you on the way back out. Terrible.

This breaks save games, probably. I don't like that, but...

[luxaritas]

So, a few thoughts here:

• Technically, we could type it with a giant tuple type. That said, it's still rather nasty code
• I see no reason why this shouldn't be separate properties, as you've said
• All of this should totally be cached in (a) Folder somewhere and not in undoblock (or not be cached at all, wrt # pairs, etc) If we want to include it in saves in order to have expedited solution loading and to see stuff in the design browser, great! We just pull the info at submission time, and inject it into the appropriate cache at load time.
• As far as the current state where you have a map (for whether its pseudoknotted) which wraps an array (for the temperature) which wraps the actual values - this is also gross. If you really needed that (which we don't, since it should go in Folder) we should do it like we do in Folder (!) - have a map that goes from an object containing all keys to values of the cache. EG, {pseudoknots: true, temp: 37} -> {gus: 12, ...}
• This not only breaks savegames, but solutions submitted to the server. We definitely need to maintain backwards compatibility until whenever those might be able to be migrated.
• This may not be a bad time to introduce an EternaSaveGameManager that can handle saving and loading multiple versions of our "save format" - either by introspecting the structure or by including a version number. Or both, if we want to have an explicit version but also when we inevitably forget to handle a change somewhen.

[everyday847]

Yeah, I think I agree with you on all fronts. My one question is how to elegantly implement an EternaSaveGameManager -- that doesn't just turn into an enormous branching demon (i.e., read version (or absence of version for pre-ESGM saves), then branch off in one of 8 directions, then 9 directions, then...) -- maybe this does not matter long term. Certainly, we should build the ESGM with support only for 'version-free' saves first and confirm nothing breaks.

(It may just be that we want to support effectively one year's worth of save versions at all times.)

[luxaritas]

You could build this in such a way that it "upgrades" a structure from one version to another, maybe? Seems at least somewhat cleaner, with one handler per version

[everyday847]

Maybe. But let's say we start writing out baz in version 9. Now we have to read in a null baz for version 8 saves, meaning that we need a null baz handler elsewhere -- sort of square one. It might be a bit neater, but far from all the way, probably.

As far as I've ever seen, data versioning's just miserable no matter what you do.