Feature values which depend on combinations of choices

[olzama]

Sometimes we need to make a decision about a feature value based on a combination of choices, and we may need to do that more than once. Several approaches exist. We need to decide which approach to take and normalize the code with respect to that approach.

My secondary concern is the new globals. There are already (true) globals in the code that could be removed, but adding new ones seems mediocre. I understand there may be a philosophical divide here, but I'm sort of confused about their purpose? It seems you're trying to avoid adding the same feature twice, but that shouldn't be a big deal? Also, other libraries already do this (going back to SFD days) by storing choices in the choices file. Something like this seems preferable. In the choices refactor work I've done, I've thought that it would be handy to have a copy of the user's input choices and an "enriched" choices, and maybe this would accomplish what you're going after? As I mentioned in the comment though, this can be addressed later.

Yeah, this is by all means unfinished (and yes, a philosophical divide may emerge in a discussion like this, I suppose!).

What I was after is not having to compute a value for a feature more than once. There are decisions which need to be made based on a combination of choices, for example: are there question particles which exhibit diverse behavior with respect to what type of questions they occur with? Having to compute that twice (or more than once) is not ideal. Now, what I strongly believe needs to be avoided is duplicate code (because typos and bugs); but what could be done instead of the "globals" is a function that gets called in all places. Then the value would be computed more than once but at least by the same place in the code. Let's open an issue about this.

Yes, "enriched choices" sounds like something I am after here, perhaps.

Originally posted by @olzama in #502 (comment)