Authors CurseForge

Few months ago, there were discussions about whether the event handler in ParserLib should pass the fields directly or grouped as a table, i.e. function Parser_Hit(source, victim, skill amount) or function Parser_Hit(info).

The current Parser-2.0 in svn branch used the first approach, however the variance of combat logs is causing me a lot of trouble in sorting out a clean list of event handler args for each Parser event. Especially when no other people is interested in touching this shit and I no longer have that much free time to review all the possible patterns manually.

Passing a table has the advantage of dynamic fields, which is very useful with the fact that the WoW patterns keep changing, and a message type can have many possible fields. If a message type, e.g. 'hit' has 20 possible fields, most of the time only 4~6 of them are actually assigned a value, it's very annoying to have a function with 20 args just for accessing all the possible fields.

The only real disadvantage for passing a table is that users might change content of the table, but Jerry proposed a read-only table approach which would solve this problem at http://www.wowace.com/forums/index.php?topic=3272.msg64012#msg64012

I'd like to discuss this idea with those who concerned, if everyone agree on keeping the table approach, then Parser-2.0 can probably be released sooner, as I don't have to spend the effort to sort out all the possible fields for all messages types. Blizzard combat logs are a mess, and I don't want to have to look through all of them again if I don't have to, it was a nightmare to me.

Parser-2.0 was delayed for so long because I no longer have so much time on modding, I have almost stopped playing WoW for 3 months for my real life stuff, some people were interested in helping on the development of Parser-2.0 so I started working on it, but later they were busy at their own things and no longer have the time to help, so I'm all alone again.

Now the Parser-2.0 in svn branch is working fine, except the fact that I have to rearrange/review the pattern fields if I don't want to have a event handler which receives 20 args.

For example you know the 'hit' type have possible booleans of isCrit, isDOT, isSplit, isCrushing, isGlancing, which takes 5 args, which is actually unnecessary, as { isCrit, isDOT, isSplit } and { isCrushing, isGlancing } are mutually exclusive to each other in the set. So merging them into maybe 'hitType' = [hit|crit|dot|split] and 'hitModifier' = [none|crushing|glancing] would reduces 5 args to 2. Yes, that sounds easy, but in order to do that I have to look at each of the fields, think if they're possible to become inclusive, then sort out a nice list which places more important fields at the front of the args list. Who knows if crushing blows and glancing blows might actually appears at the same time in the future? Most likely it won't happen, but what if Blizzard's mind changed and it actually happens? Release a new Parser-2.1 API just for a slight change of the fields? or Make 'hitModifier' deprecated and add back another 2 args isCrushing and isGlancing?

It's an example of the troubles I'm having when I am forced to have a static function args (which is the API, can be incremented, but not modified after release), when the combat log messages are so dynamic and sure to be changed in each patch.

Passing a table solves all the problems, I don't have to care if isCrushing and isGlancing are exclusive or not; if some fields are no longer possible, just let them be nil forever; if there are new fields, just add them to the table. I don't have to care about that 'skill' should be more important than 'isSplit' and should be placed in the args list before 'isSplit'.

When I had the discussions with some authors (which is quite long time ago), many people simply think that table = evil, no one should use a table at all, ParserLib used a table and so it sucks. But yet no one wants to help on 'de-table' the patterns. I no longer have that much free time to do that, I also don't want to touch that mess. An API really shouldn't cost me 80% of all the efforts to develop, so I'd like to ask again what you guys think about the API in Parser-2.0.