It's always frustrating never to finish the parade of new major changes to implement. First the plugin-package-format restructuring, then the plugin-command-handling restructuring, then nested-plugins, and so on...it can get annoying.

But that doesn't stop the parade from marching on.

Anyway, there are some significant changes that need to be made to Supybot on a very core level. The first I'm thinking of involves permissions. Someone compalined (in the user forum, iirc) about the fact that in order to give users permission to call a certain command (we'll use Misc.list as an example), he had to give them not only 'Misc.list', but 'Misc' and 'List'. He complained that that was a pain in the butt, and he's right. The most specific permission should definitely override all generic permissions.

The problem with implementing this is that we have no way of knowing whether, when we say "Does user X have capability Y?" whether the answer is returned as the default, or whether it's returned because user X has really been given capability Y. That is, we need not a binary response to that question, but a trinary one. If the user has been given the 'Misc.list' capability, we need a True answer to that question, if the user has been given the '-Misc.list' capability, we need a False answer to that question, but if the user has neither of those capabilities, we need a, "I don't know for sure" response.

So our capabilities system needs reimplemented to handle that.

Jeremy

So, how does this sound?

User definitely has that specific capability: True
User definitely does NOT have that capability (or has that specific anticapability): False
Ambiguity: raise an exception

Other than creating custom return values here, I can't think of how to do this except for using an exception. And it makes sense too, because that is exceptional behavior ...

I actually just (as in two seconds ago) thought of a better solution to this problem. One that's even backwards-compatible with the current method.

I was going to describe it, then I figured I'd just write a little code that would show the idea better:

    class CapabilityResult(object):
        def __nonzero__(self):
            return False # Just for safety sake, in case of a bug in a subclass.

    class Has(CapabilityResult):
        def __nonzero__(self):
            return True

        def confident(self):
            return True

    class HasNot(CapabilityResult):
        def __nonzero__(self):
            return False

        def confident(self):
            return True

    class MightHaveSoCheckDefaults(CapabilityResult):
        def __init__(self, msg, channel, ...):
            self.msg = msg
            self.channel = channel
            ...

        def __nonzero__(self):
            default = getDefault(self.msg, self.channel, ...)
            return default

        def confident(self):
            return False

Get the drift? Then functions that get these values can check whether the value is "confident" or not.

Jeremy