Ability to have complex logic in command matchers about slack-ruby-bot

[dblock]

If you look at how this bot framework is constructed you have hooks, such as message that respond to anything, and then it's all the way up from there trying to make it easy to do common things. You can definitely write your own message hook and do anything there and shortcut the whole framework.

One level higher, you can override invoke in a command, but that's leveraging some internals and hijacking what we do here half way.

So I think I'd welcome a proper way to do this, I think we want:

match do |client, data|
  #=> returns `nil` if not matched
end

Or we could extend match, command and operator with additional conditions, so

command 'foo', if: ->(client, data) do
 #=> returns true if should be evaluated
end

Would love a PR!

[synth]

It seems to me the simplest implementation would be your first suggestion(thats what I was thinking first anyway). All that would need to be done is to amend the logic in commands/base.rb#invoke and we'd be in business.

Something like(this is untested):

      def self.invoke(client, data)
        self.finalize_routes!
        expression, text = parse(client, data)
        called = false
        routes.each_pair do |route, method|
          match = route.match(expression)
          match ||= route.match(text) if text
          next unless match
          next if match.names.include?('bot') && !client.name?(match['bot'])
          if method
            result = method.call(client, data, match)
          elsif self.respond_to?(:call)
            result = send(:call, client, data, match)
          else
            fail NotImplementedError, data.text
          end
          break unless result
          called = true
        end
        called
      end

Although I must say the dsl approach is nice too, just more work...

If you're cool with this approach, I'll try to find time to whip up a PR

[dblock]

I think relying on the return of the method is going to make it very hard to debug for people and also has potential to break backward compatibility. Generally my rule of thumb for these is "what do developers want to write", so I would try the DSL approach, it's more work, but it's something that is not relying on a side effect.

Feel free to disregard what I said though, lets talk it over code that works with passing tests ;)