On 23 August 2017 at 09:40, roger peppe <[email protected]> wrote: > On 23 August 2017 at 09:23, MartinG <[email protected]> wrote: >> Thanks for the fantastic explanation folks. >> >> I wonder if I can ask advice on how to improve my use case. I have a struct >> type that represents a state machine and each state is handled by a >> different method on that type, each with the same signature I use a >> function variable to represent the current state and it is simply set to >> point at one of the methods. The state is modified frequently, hence my >> problem. >> >> The options I can think of are: >> >> 1) Define another type (probably based on int or similar) representing the >> current state and switch on that instead of using a function type. This >> feels inelegant and avoids using function types on one of the scenarios they >> seem to be designed for. >> 2) Define non-method related functions with a similar signature, but that >> also take my base type as an additional parameter. I believe this will >> avoid the allocation, but also feels wrong because these functions really >> "belong" to my base type so should be methods. >> >> Any other possibilities? > > You could use method expressions. > > For example: > > https://play.golang.org/p/9H1n-CevNJ
Actually, it occurs to me that using method expressions in this way is actually more powerful, because the state can be manipulated independently of the state transitions. You could use this, for example, to fork the state machine and run it concurrently from an arbitrary state. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
