The problem is that when A only registers to CHAT_MSG_COMBAT_SELF_HITS and Parser_Hit, I think A shouldn't receive a Parser_Hit event at all when CHAT_MSG_COMBAT_HOSTILEPLAYER_HITS was fired. But I can't control who will receive the Parser_Hit event, or ca
IDs and counters only let me know who registered to what Blizzard events, it doesn't solve the problem.
If there isn't any better solution to this, then I think I can only pass Blizzard event as an arg to Parser_Hit, addons should expect to receive Parser events even when they didn't register to the that Blizzard event - that means they may optionally tell ParserLib what Blizzard events they're interested, but expect to receive Parser_Hit from all possible Blizzard events.
In that case the API may look something like this:
-- pass self to ParserLib so when you register to Parser_Hit, ParserLib knows that you have already suggested a Bz event and will not register to all hit-related Bz events.
-- actually registers to Parser_Hit.
that looks weird to me, but at least it makes the suggestion part completely optional?
At the back of ParserLib it would just store a table of addon reference and their interested Bz events. ParserLib listens to AceEvent_EventRegistered for ParserLib events, when someone registers to ParserLib events, ParserLib registers to all related Bz events if the addon reference doesn't exist in the table, otherwise ParserLib registers to possible Bz events in the suggestion table.
Using a unique ID for each event allows the user of parserlib to solve the problem.
event -> parserlib
eventID = eventID+1 (=101)
self.eventID=parserlib:GetEventID(). returns 101
parserHit(eventID, ...) ------>client
if self.eventID != eventID then return end
... otherwise its from an event we want
Even better if the eventID was in AceEvent - since maybe its possible they could get parserHit before the bz event (at least that how i understand it events fired from event handlers create an event stack)
Letting the addons users store information for you prevents you having to maintain tables internally.
This is essentially the "Visitor" design pattern without the OO
I still think that using a sequence counter that increnments on each event will solve most if not all of these issues. Each source event CHAT_MSG - gets assigned an ID which can be queried when you get derivative events eg. Parser_Hit.
You can then use some logic to ignore the event based on this ID.
In your case, you would register for CHAT_MSG_COMBAT_SELF_HITS and Parser_Hit. In the CHAT_MSG you would save the ID, and process any subsequent event with that ID.
So if the event CHAT_MSG_COMBAT_HOSTILEPLAYER_HITS generates Parser_Hit, you will not have a matching ID when Parser_Hit fires...so you would ignore it.
Using an ID tied to the source event solves alot of ambiguity issues (with events that fire as a result of the original event) and is extremely cheap to implement.
I dont know where you are at today and some of these posts are a month old. But I thought I'd try to join in the discussion.
Here's what I got from reading this thread:
The idea of mapping each parsed string to a unique event is a good one - similar to SAX in concept.
'I hit chicken for 4.'
Lets say that comes in via 2-3 different CHAT_MSG_COMBAT* events(if you are in a raid or party or solo), you would want to just register for one abstracted event, and let an intermediate library keep up to date on which message gets fired for what - abstracting the whole blizzard event system (for combat).
So when I register for Parser_HitSelfOther, the intermediate would register the 2-3 events needed. And I would always get Parser_HitSelfOther.
This would eliminate most of the if/then/else that goes on in e.g. sct.
if (info.type == "environment") then
elseif (info.type == "hit") then
Since LUA isnt a strongly typed language using separate callbacks rather than one allows you to preserve type inforomation in a sense.
sct has an additional challenge, it processes some of the blizzard events internally. It seems like you could add the abililty to recieve Pre* Events, and allow you to switch off event generation by the parser for that message and that addon ID.
If i register for PreHook__CHAT_MSG_COMBAT_SELF_HITS, i could somehow turn off the event which parserlib generates, but only for my addon. You could use an incremetal counter and assign every event a sequence number, then pass this to the prehook function, and provide it in the subsequent parserlib callback. Basically, in the PreHook the addon would save the sequence number, and then when parserlib generates the registered event, the client could use that to ignore the event. This way you can keep the client decoupled from the actual CHAT_MSG_COMBAT_* event.
The ideal case would have an addon like sct not register to listen to the actual blizzard events at all (at least the ones that parserlib handles) -
EDIT: I just realized that this post is off topic. =)