Consider exposing message tags

[ShaneMcC]

I'm not sure if this is useful but we should consider exposing message-tags to clients.

This would be a rather annoying change to pretty much every parser callback, and at the moment I don't think there are any non-parser tags (eg tags that would affect the way the client deals with the line) that would justify the effort. But maybe worth thinking about in future?

[csmith]

I'd quite like the DMDirc parser to emit events at some point, instead of the current million-and-a-half callbacks.

I was planning on wrapping the parser in the plugin, but If we did it at the parser level instead it'd make things like this a lot easier (as you can add fields to the events without breaking anyone using them).

[greboid]

That's a really good point, add a simple dependency on MBassador and life would be a lot easier for anyone implementing something on top of the parser and would give you the ability to add awesome things without breaking existing implementations. (Also if you add dependencies we could nag you to add DI to it :))

[csmith]

You could even do it without the dependency - just have an interface with a
"publish" method and have parser.setPublisher(blah).

Then it's trivial for people using the parser to drop in any event bus they
like, or some kind of adapter to do other stuff (like call callbacks).

On Thu Sep 25 2014 at 10:40:29 Greg Holmes notifications@github.com wrote:

That's a really good point, add a simple dependency on MBassador and life
would be a lot easier for anyone implementing something on top of the
parser and would give you the ability to add awesome things without
breaking existing implementations.

Reply to this email directly or view it on GitHub
#19 (comment).