|
|
The only part about modes where there is really any point in overriding is who can set them. In which case, it's easy to set a mode hook (there's one for usermodes at least) and add (but not remove) to what privileges are needed to (un)set. For behavior purposes, you can just test the mode, or for parameterized modes, test its value. Modes don't have a single "do stuff" bit that controls their behavior, rather it's spread across whatever other functions they effect (eg: +m's behavior is part of the PRIVMSG/NOTICE code, +iOAlLk is part of JOIN, and usermodes are pretty much the same deal), so it isn't a simple question of replacing a single function with another. I guess you could change the bit for the mode, but now the old version doesn't work anymore, and it's already simpler to just use a different mode character. Perhaps a good example of how this might be useful is needed.
Extended bans, however, are a whole different beast, and are nearly analogous to commands - they have a "do stuff" part that could theoretically be overriden for some purpose or another - other than the "do stuff" part isn't run directly but rather automatically every time someone joins, messages the channel, or changes nick. But despite being fired by three different events, all the behavior to an extban is generally one place (exception: syzop's textban module), so it's a simple matter to replace old with new.
|
