Proposal to change send_log_message calls to event dispatches.

[scragly]

trafficstars

Rather than fetching the ModLog cog and then calling or shortcutting the send_log_message calls in every cog, the idea is to utilise the event-based dispatch system (bot.dispatch) to emit a new event type that provides all the log args, and the ModLog cog will simple define a listener corresponding to that event which will trigger on emit.

It's likely more DRY, doesn't require importing a cog for type hints like are currently occurring, and will allow us to maybe control where each log type is sent within the ModLog logic instead of changing it in all the other cogs.

Any thoughts on the idea are welcome.

[MarkKoz]

I'm not a fan of the modlog in its current state and welcome improvements to it. I particularly dislike that the cog is used in other cogs. Would you mind demonstrating how the dispatching would work? I'm not familiar with it.

@scragly Have you made any progress on this?

[scragly]

I haven't personally started an implementation but it's actually pretty simple to do so I'll discuss it when I'm online next with you.

[scragly]

bot.dispatch is a low level bot method that's considered for internal usage.

It allows you to have the bot retrieve all base handlers and listeners for a specified event name:

bot.dispatch("myeventname", *args, **kwargs)

If there's no base handlers or listeners, it silently fails in a manner that suits this type of non-essential logging, without breaking other usually more important functionality of the bot.

This also allows us to define listeners essentially anywhere, the same as any other event type.

@Cog.listener(name="myeventname")
async def some_handler(self, *args, **kwargs):
    ...

@Cog.listener()
async def on_myeventname(self, *args, **kwargs):
   ...

As bot.dispatch is a low level API, I'd recommend wrapping it in a helper method that's specific to the logging, such as bot.send_log or similar. This allows for a simple higher level API, and means we don't require adjusting multiple locations if the low-level API has any adjustments in later updates.

[mbaruh]

It seems to me that this should just be a utility function imported from another module. It's a general purpose function to format a bot message (despite its specific name), and it could easily be made a static method, as the only usage of self is to get the bot instance, which can be imported or sent as an argument.

This is what we do with helper functions which are used in multiple modules, seems appropriate here as well.

[wookie184]

I agree. Making this a util function is definitely worth doing as it'll help reduce some inter-cog dependencies.