Discussion for re-designing event middlewares

[andersfylling]

The current middleware design allows you to affect the internal state of a handler-specification[1] before the handler(s) are triggered. The middlewares themselves are simply given the event instance and returning it when done; while returning a nil, causes the chain of middlewares/handlers to be considered cancelled.

The proposed change by @coadler is to make it similar to how http middlewares work. The middleware would then be given an function pointer for the next middleware and would have the option to call the given function pointer. By not calling it, the handler-specification[1] chain stops/is considered cancelled.

Any discussion regarding this takes place here, arguments for, against, etc.

[1] A handler-specification is the combination of middlewares, handlers and life time controller assigned to DisGord by calling Client.On: eg.

client.On(disgord.EvtMessageCreate, IgnoreBotsMdlw, MustHavePrefixMdlw, CommandHandler)

[nikkelma]

I happily support pushing disgord towards established Go ecosystem patterns, including this refactor to handlers. I prefer sticking to the ecosystem patterns when appropriate because it allows reusing all the effort already put into edge case considerations, testing, and other patterns building on this foundation.

[andersfylling]

That sound like a good point, which is also why I'm considering it. I'm just unaware of the current practice.

I also wonder if adding context to middlewares would be benefitial - by having a constructor method in the Controller. But yeah, I guess there's a lot to consider