Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhancement: Integration with signalslot? #23

Open
sjlongland opened this issue May 20, 2015 · 4 comments
Open

Enhancement: Integration with signalslot? #23

sjlongland opened this issue May 20, 2015 · 4 comments

Comments

@sjlongland
Copy link

Just a thought, is it worth providing some integration into signalslot so the events generated by the state machine are exported to other objects as "signals"? I've been managing this by hand in my own code, and found it a very powerful way to interact with Fysom.

It could be an optional feature turned on by specifying what events you want signals created for in the constructor. e.g.

fsm = Fysom({ 'initial': 'green',
          'events': [
              {'name': 'warn', 'src': 'green', 'dst': 'yellow'},
              {'name': 'panic', 'src': 'yellow', 'dst': 'red'},
              {'name': 'calm', 'src': 'red', 'dst': 'yellow'},
              {'name': 'clear', 'src': 'yellow', 'dst': 'green'} ],
          'signals': ['onentergreen','onenteryellow','onenterred', ...]})

The signals could be properties with _sig appended to the name to avoid confusion.

signalslot is here: https://github.com/Numergy/signalslot

If there's interest I might look into implementing it proper.

@mriehl
Copy link
Owner

mriehl commented May 21, 2015

Seems like a good idea, it would alleviate the burden of dealing with many callbacks that simply defer to other objects.

Where would the callable slots be defined though? On the fsm?
Or would you add a signal_slots dictionary to the constructor?

@sjlongland
Copy link
Author

On 21/05/15 16:52, Maximilien Riehl wrote:

Seems like a good idea, it would alleviate the burden of dealing with
many callbacks that simply defer to other objects.

Where would the callable slots be defined though? On the |fsm|?
Or would you add a |signal_slots| dictionary to the constructor?

I was simply thinking you'd pass in an option in the constructor, and it
would create Signal instances for each named signal and bind it as a
callback.

If you wanted to pass a specific Signal instance for a given signal
name, then you could conceivably make this parameter optionally a dict
mapping the signal name (== callback name) to a signal instance.

Some untested code:

import fysom
import signalslot

class SignalFysom(fysom.Fysom):
    def __init__(self, *args, **kwargs):
        signals = kwargs.pop('signals',{})
        callbacks = kwargs.pop('callbacks',{})
        if signals is not None:
            if not isinstance(signals, dict)):
                signals = dict([(name, \
                    signalslot.Signal(name=name)) \
                        for name in signals])
            for name, signal in signals.items():
                setattr(self, '%s_sig' % name, signal)
                if name in callbacks:
                    signal.connect(callbacks.pop(name))
                callbacks[name] = signal.emit
        super(SignalFysom, self).__init__(*args, \
            callbacks=callbacks, **kwargs)

That would in theory, hook the emit method of the signal as the
callback. If a callback of the same name is given, it gets added as a
slot to the signal before the signal is added.

Regards,

Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
...it's backed up on a tape somewhere.

@mriehl
Copy link
Owner

mriehl commented May 22, 2015

I like the approach. If you have time to implement this, I'd definitely merge it. I have a few personal projects where the integration with signalslot would greatly simplify the code!

@TTimo
Copy link

TTimo commented Sep 1, 2015

+1 .. I use both fysom and signalslot, would be interesting to play with a tighter integration

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants