I think the table approach works just fine and have no problem with you keeping it that way. I can't imagine anyone would want to iterate through the table, they should be reading the API and looking for the specific fields that table can have, given the event.
In 2.0, can we still register at the blizzard event level if we want more granularity on what is parsed? My only issue with the "Parser_Hit" hit approach is that there's possibly a ton of events I don't care about there, so potentially a lot of wasted events and overhead parsing them for info that's not needed (for a given mod). Just as an example, SCT only cares about "hit" events that happen to the player and SCTD only cares about "hit" events that the player does.
You can for detecting when someone starts to cast a spell and such (instead of parsing "bob starts to cast..."), that is what the new built in enemy casting bars use. But you couldn't use them for normal combat parsing. Those events return nothing about the damage done, resists, etc...
Suggestion: would it be possible to roll all the "localized optimizations" into the base file? I know having separate files for each localization is nice for maintenance sake, but its a real pain having to include multiple localizations for a library. I think it would be much simper/nicer for addons to just have to include 1 file in their TOC, instead of the current 4, with the potential for more. I realize all these extra files are optional, but since they do help performance quite a bit I think they could be safely rolled into the main file.
I don't call it =) Basically with SCT custom events, if a custom event is found everything about what to display comes from the custom event settings. So in those cases I don't care what Parserlib parsed out. I was just saying that in an ideal situation I could do the custom event check/parse before ParserLib ever got the event and never send it to ParserLib if a custom event was found. However this is a very specific case probably unique to SCT, so I wouldn't expect ParserLib to worry about it. Might be some way to do it with hooks, but haven't really cared enough to mess with it yet =).
Of course, ParserLib can be used my multiple clients, so doing that wouldn't work at all. So just ignore me =)
Either way works for me, but if passing the info as args reduces table churning, then makes sense. I think you could do it with the old way too, but would require specfic args to always be in a certain order, so the table appraoch made that much easier. However, as long as the type was always the 2nd arg, it would work.
Question, will the blizzard event and args still be available with the new Parser fired events? If not you may want to include them in the list of args. SCT for example uses them to do custom event parsing, because if a custom event is found it ultimately ignores the parsed data supplied from ParserLib. I wanted to find a way to do the custom event parsing and if one was found, not even call ParserLib for that event to remove that processing, but didn't see any easy way to do that.
My thinking was you would register the chat events with the specific chat events that you know you want, but you wouldn't be "listening" for those events, you would only listen for the Parser_Hit, etc...This way in your example they would only register for events that contain self damage, then listen for the Parser_Hit, Parser_Miss, etc...
But I think like you said, if there is a way to do both or just select what type you want upon registering would work. But I'm not sure how much overhead there would be having to throw two seperate events. If its affected performance at all, would probably be best just to pick one.
Just thinking here, but instead of returning an event for that specific chat event, why not return a parserlib event that is of the info.type. For example "PARSER_ENVIRONMENT", "PARSER_HIT", "PARSER_HEAL", etc...
Seems like that would work out better than having to figure out what an event is after getting the custom event. But I could just be misunderstanding your idea =)
It would also be nice if ParserLib could support then new BulkEvents feature of AceEvent. I imagine a lot of mods will begin to take advantage of it. Not sure how diffcult that would be to add, but just something to consider.