search

sopel-irc / sopel

:robot::speech_balloon: An easy-to-use and highly extensible IRC Bot framework. Formerly Willie.
https://sopel.chat
Other
949 stars 402 forks source link

Nicer API support for multiple recipients / `TARGMAX` #2343

Open dgw opened 2 years ago

dgw commented 2 years ago

Since Sopel is now aware of TARGMAX, we have the foundation of more efficient message sending available. Right now, plugins have to jump through some hoops in order to use it; see e.g. #1859.

I'm definitely in favor of the following conveniences:

In a perfect world this would "just work" as part of the existing say() & friends, but we need to think about that carefully. I have no concerns about automatically correcting comma-separated lists in string form—that's just to prevent plugin code from sending stuff with too many targets that the server would block anyway. Moving to support a list/tuple/set as recipient is the one that really requires forethought. I just don't want to complicate the bot methods available any more than necessary. One could argue there are already too many. (One could also argue that there are already too many optional parameters in say() et al.)

There will be discussion aplenty, I'm sure. This certainly won't be part of 8.0.

A relevant past comment I found is quoted below, to help start us off.

Originally posted by @Exirel in https://github.com/sopel-irc/sopel/issues/1525#issuecomment-490490387

The more I think about multi-recipients, the more I believe we should not handle these cases in methods like say and alike, but instead to add new methods, like multi_say.

  1. changing recipient to recipients is a breaking change, as there is no restriction on the argument to be a non-keyword one,
  2. having to resort to type-sniffing is doomed to fail, for example if someone provide a tuple instead of a list, or alike
  3. the most common use-case for say or reply is to reply to the sender of a trigger, and it is very unlikely that anyone want an implicit "send to multiple recipients"
  4. explicit is better than implicit

So in conclusion […], I suggest […] to add new methods, instead of changing existing ones.

Exirel commented 2 years ago

That would be a nice "new feature in 8.1". 👍