|
07/08/14, 09:11 AM | #1 |
|
LibConstantMapper
While trying to figure out wich unambigious Chat Category Constant name relates to wich category I ran into the issue that the Constant Names are the keys in the global table. They can be identified via Pattern Matching, but they are not a subtable that you can easily itterate over.
Doing excessive pattern matching is bad for performance. Also there are other similary organised groups of values (like the Chat_Channels or all the Event ID's) you might want to find an easy match for. So I started development on this library. It consists of two files: mappings.lua Lua Code:
If I also want the chat channels using this library, I just have to modify it like this: Lua Code:
main.lua Lua Code:
That way I get a easy to itterate over table containing wich ConstantName matches wich Category. Going over the whoel global table is a lot faster then I anticipated so maybe I switch to a "retreive on demand, but cache" approach instead. Of course the whole thing will use libStub to avoid multiple execution in the final version. I just wanted to ask if there are any mistakes in this code I have to look out for. |
07/08/14, 10:37 AM | #2 |
|
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:
Lua Code:
Lua Code:
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 ) Last edited by merlight : 07/08/14 at 10:40 AM. |
07/08/14, 12:15 PM | #3 |
Some more suggestions:
Lua Code:
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 |
|
07/09/14, 04:25 AM | #4 | ||
|
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.
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. Last edited by zgrssd : 07/09/14 at 04:38 AM. |
||
07/09/14, 08:31 AM | #5 | ||||
|
Skip down to *CONSTRUCTIVE* if you only want something constructive, this below is just rant
Lua Code:
Someone else might instead do it this way: Lua Code:
nameIt1 returns the first key with matching value, nameIt2 returns the last. Not to mention that the order of values in mapping depends on the order in which you get them from zo_insecurePairs! Which may be different every time you /reloadui, so addons using any nameIt function might behave strangely sometimes. I know it's hard do deal with conflicts properly, but if it's done in a library, at least it can be done consistently. *CONSTRUCTIVE* You could: 1) Add type requirement to your mapping spec. For example, "only int values allowed", everything else thrown away. 2) Sort your data={{value=5,key="foo"}, {value=5,key="bar"}} pairs table on value and key (sorting elements with equal values on key is important if you want consistent search results). Or zo_binaryinsert right away, instead of table.insert's and table.sort afterwards. 3) Provide a lookup function which would zo_binarysearch for given value in the sorted data. Last edited by merlight : 07/09/14 at 08:34 AM. |
||||
07/09/14, 11:21 AM | #6 | |
|
My experience tells me that a int-indexed, properly formed array consisting of key/value tables offers the best overall usage while still having acceptable looping performance. Looping over the array with # and comparing a string to "something" is going to have the same performance as asking the system for the value to key "something". Because all those tables are "under the hood" are one List without allowed duplicates and one with allowed duplicates. Also I cannot guarantee that any value will be there only once. That is simply a matter of how the data looks and the patterns/exclusiong are set. Better ending up with the same key twice in the array (easy to diagnose) then having sometimes the one key in use, sometimes the other (hard to diagnose). |
|
ESOUI » AddOns » Released AddOns » LibConstantMapper |
«
Previous Thread
|
Next Thread
»
|
Display Modes |
Switch to Linear Mode |
Hybrid Mode |
Switch to Threaded Mode |
|
|