event.reaction decorator inheritance

[Korijn]

Consider:

class Parent(ui.Widget):
    @event.connect('foo')
    def on_foo(self, *events):
        pass

class Child(Parent):
    @event.connect('bar')
    def on_foo(self, *events):
        pass

Should Child.on_foo be triggered on foo and bar? I guess it depends on the situation, and a kwarg may be nice to control this behavior.

class Parent(ui.Widget):
    @event.connect('foo')
    def on_foo(self, *events):
        pass

class ChildA(Parent):
    @event.connect('bar')
    def on_foo(self, *events):
        pass  # will be triggered on `foo` and `bar`

class ChildB(Parent):
    @event.connect('bar', inherit=False)
    def on_foo(self, *events):
        pass  # will be triggered on just `bar`

... where inherit=True is the sensible default, I think.

[almarklein]

If a user connects to on_foo(), where on_foo() is already defined in a super class, it can be because:

• A) she/he was not aware that on_foo() already existed.
• B) she/he wants to redefine the connections (not inherit).
• C) she/he wants to add connections (inherit).
• D) she/he wants to change the behavior of the handler.
• E) A combination of B-D or C-D.

For B and C, I think you're suggestion makes sense.

For A, we should perhaps raise a warning/error unless the alternate syntax is used that makes it explicit that this is an overloaded handler.

For D, there is super(). Though, what if the connections should remain unchanged? should the decorator be left out? Or a call with no positional args?

[Korijn]

For A, we should perhaps raise a warning/error unless the alternate syntax is used that makes it explicit that this is an overloaded handler.

Yes! Great suggestion.

For D, if you want the connections to remain unchanged:

@event.connect(inherit=True)
def on_foo(self, *events):
    pass  # will be triggered on `bar` and `foo`

Without the decorator, I would say that any random passer-by developer will assume that it's not an event handler (or at least that it isn't connected to any events). It will feel very magical (and unpleasant) if it turns out to be connected after all.

[almarklein]

Yeah, that's something we might want to check in general; whether an overloaded method was a prop/handler/emitter in a super class.