> On Mar 16, 2021, at 1:09 AM, Chris Withers <ch...@withers.org> wrote: > > > On 15/03/2021 09:34, Glyph wrote: >>> Right, but as best I can tell, outputs in automat have to be defined as >>> part of the state machine class, I need targets only available after class >>> instantiation to be notified. >> Outputs are just methods, so it sort of depends what you mean by "after >> class instantiation". You can call whatever you want /in/ an output. > > Right, but then I'd have to maintain my own list of subscribers and figure > out a way to duplicate in that logic in each of the output methods defined on > the machine. > >>>> Again... have outputs. I think there's something you're leaving out about >>>> how you want to have some /generalized/ output, but without knowing a bit >>>> more it's hard to say how it could help more :). >>> >>> I think it's what I said above. TBH, I'm probably going to end up writing >>> "yet another state machine class" that does just what I need, but I think >>> that's okay - not everything has to work for every situation :-) >> It sounds like what you /might/ want here is soemthing for constructing >> arbitrary machines at runtime, > > The states and transitions are very rigid. > >> and automat is all about enforcing that your machine is static so that (for >> example) it can be visualized statically. So yeah in that case, different >> library. > > Take this example: > > class LightSwitch(object): > _machine = MethodicalMachine() > > @_machine.state(serialized="on") > def on_state(self): > "the switch is on" > > @_machine.state(serialized="off", initial=True) > def off_state(self): > "the switch is off" > > @_machine.input() > def flip(self): > "flip the switch" > > on_state.upon(flip, enter=off_state, outputs=[]) > off_state.upon(flip, enter=on_state, outputs=[]) > > > What I'm looking to do is something along the lines of: > > aSwitch = LightSwitch() > aSwitch.flip.addListener(myCallable) > > myCallable might well be a deferred that something else is waiting on...
Thanks for the example. My opinion is definitely that this should be an output produced by both edges here, and that output should manage an observer which does this extra functionality. By modeling it as an output, you can see in your visual DFA where observers will be notified; and managing the list of observers is something that might have its own state-controlled lifecycle. You can disagree of course but I think that's a very different design idiom than automat :) -g _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
