Originally Posted by merlight
Some suggestions.
a) either allow more exludes (make it a table) to make things like this work (because Lua's regular expressions are so weak they can't accomplish this in one go):
Lua Code:
{ mapping = "Stats", pattern = "^STAT_", exclude = {"^STAT_BONUS_OPTION_", "^STAT_SOFT_CAP_OPTION", "^STAT_VALUE_COLOR"} }
b) or replace excludes with a non-mapping...
[highlight="Lua"]
[...]
Also it would be nice to have direct [value] => "key" mapping in addition to the table of pairs (I'm aware there might be collisions and the library would have to deal somehow, that's why wrote in addition to  ) |
I want the same Key to be able to pop up in multiple mappings (i.e. Events appareing ina big "all events" mapping as well as sublist for each class like guild), so non-mapping is out of the question.
The final structure for mappings might looks something like this:
1 Mapping (the mapping name)
-> with 1...N patterns to match
-> each pattern with 0...M exclusions
But that is pretty far in the future. First things first.
Originally Posted by Garkin
1) Mapping can be part of the name and pattern is defined only in special cases
2) Do not create a new global table ConstantMapperMappings, just make it accessible using the library reference
3) As merlight said, it would be nice to have direct [value] => "key" mapping, so I changed it that way
|
1) Due to the long term plans, a mapping might be able to have multiple patterns. Combinign them would just make the code mroe complex
2) The global table was only a temporary solution for my first trials. Currently I actually tend towards mappings being registered at runtime the same way you register media with LibMedia or libaries with LibStub. And only being processed on demand. if so the mappings.lua file will propably run after the actuall library and just call the register function in a loop.
3) My original idea was a [value] => "key" mapping. But that would cause issues if I ever end up with the same value more then once (the whole Chat Cat header issues pointed me at that).
The output tables are designed to be itterable via # operator, no use of "pairs" needed. But taht is only personal preference of int indexes over string indexes.
Not using the value as key also means I can accomodate non-key worthy values. For example, afaik "" is a valid value. But not a valid index. BugEaters inability to deal with nil and "" values pointed me towards that issue.
A simple int indexed array of key&value allows a lot more ways to process the data.
Edit (too 3):
The more I think about it, the better my idea sounds. The global table is full of values that would never make a valid index for a table: empty stings, functions, other tables - non of that could ever make a proper index. Plus sometimes the same function/table might be used as value multiple keys (so I had the same index used multiple times).
Clear index-worthy int and string values seem to be a odd thing in the global table, rather then a common one.