Three Dollar Quill

Minor technical issue: worked around!

Time management: still in terrible shape!

The next step in my quest to carefully design the environment on which to build stuff in Lua, is to figure out how I want to do stuff like "annotate fields with their name".

My general feeling is that things should work like { { field = {...} } }, where there could be many "field" tables, and the {...} corresponds to a table that gets passed to converter_function_passed_by_client_code(table.unpack(v)). That way, the current behavior of the enum module could be approximated by mapping function(field) for k, v in field do table.insert(v, k) end return field end over ipairs(fields_table).

There are some issues here. I think I want to have similar power to table.insert, but doing it like this means that the field tables get modified in place, then collected into a new table, which feels not-quite right. Like, either it should return a new table without touching the original, or it should update the original table and return the same table. I don't know which of those I prefer from a pragmatic perspective. (My gut says "avoid mutations as much as possible", but if I felt that was worth basing my pragmatic stances off of, I wouldn't be doing this in Lua.)

The "don't look inside the sausage factory answer" is to come up with an alternative to mapping over an ipairs that just loops over the table and assigns the result of the mapping function over the existing value, regardless of whether they're the same.

I'm cutting this entry off for now, but now I've got the next question for later:

Is that idea something I'd want to reuse in other contexts, or just some form of utility function I'd want for building up this kind of data?

I'm going to need to phrase this question very carefully, due to the nested structure of the tables, and the number of functions I'd like to have in play. I'll take about a day to think about this, at least. For now, I need to get ready for bed.

Good night.