Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: State Trooper – Tiny, no frills state machine for Go

github.com

Post reply on HN
Print view View original

41–50 of 63 posts

Re: Show HN: State Trooper – Tiny, no frills state machine for Go

#41

Post by Someone »

BSEdlMMldESB wrote: post #34
earthboundkid wrote: post #26

A state machine should have more than states. It also needs actions which cause transitions. The API should be about writing out which new state an action causes given a base state. Eg you have a modal with a button and it can be clicked or dismissed. In the open state, click and dismiss cause close, and in the closed state, click causes open. Anyway, the whole thing is only valuable once you have actions.

you mean like: > Add valid transitions between states: > `fsm.AddRule(CustomStateEnumA, CustomStateEnumB)` > `fsm.AddRule(CustomStateEnumB, CustomStateEnumC)`

I don’t like that name.

IMO, AddValidTransition would be way better. I think I would go for AddTransition, though. It’s not as if there’s also a way to add invalid transitions.

Re: Show HN: State Trooper – Tiny, no frills state machine for Go

#43

Post by jawr »

packetslave wrote: post #33
earthboundkid wrote: post #26

A state machine should have more than states. It also needs actions which cause transitions. The API should be about writing out which new state an action causes given a base state. Eg you have a modal with a button and it can be clicked or dismissed. In the open state, click and dismiss cause close, and in the closed state, click causes open. Anyway, the whole thing is only valuable once you have actions.

Commenters like you are why people don't share thing. Why make something available for free when someone like you is just going to come along and shit on it?

Commenters like you are why people don’t give honest feedback. Why review something for free when someone like you is unable to accept honest feedback even if it is critical.

Re: Show HN: State Trooper – Tiny, no frills state machine for Go

#44

Post by jnordwick »

naikrovek wrote: post #25

I am actually angry at how good the project name is.

I've written 2 in C++ for different projects at companies State Farm and State of Decay. I'm trying to write one that kind of inverts things and calling it Enemy of the State.

But yes, his name pisses me off because I didnt think of it either.

Re: Show HN: State Trooper – Tiny, no frills state machine for Go

#45

Post by preseinger »

pjmlp wrote: post #20
bsaul wrote: post #17

enums with associated values (like in swift) really are the thing i miss the most in go.

Yeah, yet another Algol 60 missing feature. I really don't get how one can suggest the iota const dance with a straight face as an alternative.

what do you think would happen if there was a comment about go on the internet that you somehow didn't see, and to which you weren't able to reply with a sarcastic and sneering dismissal?

probably some serious kind of disaster, right?

Re: Show HN: State Trooper – Tiny, no frills state machine for Go

#46

Post by TheSwordsman »

This state machine is inherently unsafe for concurrent use, because the CurrentState and Transitions fields aren't completely protected by a mutex. You already have an unexported mutex that you lock when mutating those fields, but then consumers trying to read those exported fields are not able to lock the same mutex to prevent concurrent read/write operations.

You should not export those fields, and instead make them available via methods where the reads are protected by the mutex. You'll probably also need to make a copy of the map since it's a reference type, OR make the accessor take the key name and fetch the value directly from the map and return it. I learned this when I wrote a similar simple state machine in Go ~7 years ago. :)

I'd also make sure to return `T` from the CurrentState accessor method and not `*T`, just to make it easier for consumers to do comparison operations with the returned result.

Reference on Go memory safety: https://go.dev/ref/mem

Re: Show HN: State Trooper – Tiny, no frills state machine for Go

#48

Post by earthboundkid »

BSEdlMMldESB wrote: post #34
earthboundkid wrote: post #26

A state machine should have more than states. It also needs actions which cause transitions. The API should be about writing out which new state an action causes given a base state. Eg you have a modal with a button and it can be clicked or dismissed. In the open state, click and dismiss cause close, and in the closed state, click causes open. Anyway, the whole thing is only valuable once you have actions.

you mean like: > Add valid transitions between states: > `fsm.AddRule(CustomStateEnumA, CustomStateEnumB)` > `fsm.AddRule(CustomStateEnumB, CustomStateEnumC)`

No.

The README has an example of shipment, so let’s think about that. It is a bad example though because it just has packed → shipped → delivered, which is not a real business process.

Let’s say you’re a seller, as opposed to UPS or FedEx. The first thing that happens is a customer makes an order. What happens next? Well, the customer can cancel their order. Or the order can be sent and then the customer can ask for a refund. Let’s try to model it:

Ordered + cancelled → cancelled Ordered + warehouse packing → packed Packed + cancelled → cancelled Packed + warehouse handed package to shipper → shipped Shipped + cancelled → too late, it’s still in the shipped state Shipped + return request → awaiting return Awaiting return + received return → refund Shipped + received return → no RMA, so no refund. No state change. Shipped + 30 days → archived

Etc. I am too lazy to do the full model, but you start to get the idea. The important thing is that actions happen from outside the system and then they cause state transitions based on what the current state is. Sometimes the system just stays in the state it is already is in, and sometimes the system moves backwards. Some actions can’t happen in certain states (can’t get something back before it goes out, can’t dismiss a closed modal dialog), but that’s not because of business logic but because of the real world. The business logic only enforces itself, not the world.

Re: Show HN: State Trooper – Tiny, no frills state machine for Go

#49

Post by earthboundkid »

BSEdlMMldESB wrote: post #34
earthboundkid wrote: post #26

A state machine should have more than states. It also needs actions which cause transitions. The API should be about writing out which new state an action causes given a base state. Eg you have a modal with a button and it can be clicked or dismissed. In the open state, click and dismiss cause close, and in the closed state, click causes open. Anyway, the whole thing is only valuable once you have actions.

you mean like: > Add valid transitions between states: > `fsm.AddRule(CustomStateEnumA, CustomStateEnumB)` > `fsm.AddRule(CustomStateEnumB, CustomStateEnumC)`

No.

The README has an example of shipment, so let’s think about that. It is a bad example though because it just has packed → shipped → delivered, which is not a real business process.

Let’s say you’re a seller, as opposed to UPS or FedEx. The first thing that happens is a customer makes an order. What happens next? Well, the customer can cancel their order. Or the order can be sent and then the customer can ask for a refund. Let’s try to model it:

Ordered + cancelled → cancelled

Ordered + warehouse packing → packed

Packed + cancelled → cancelled

Packed + warehouse handed package to shipper → shipped

Shipped + cancelled → too late, it’s still in the shipped state

Shipped + return request → awaiting return

Awaiting return + received return → refund

Shipped + received return → no RMA, so no refund. No state change.

Shipped + 30 days → archived

Etc. I am too lazy to do the full model, but you start to get the idea. The important thing is that actions happen from outside the system and then they cause state transitions based on what the current state is. Sometimes the system just stays in the state it is already is in, and sometimes the system moves backwards. Some actions can’t happen in certain states (can’t get something back before it goes out, can’t dismiss a closed modal dialog), but that’s not because of business logic but because of the real world. The business logic only enforces itself, not the world.

Re: Show HN: State Trooper – Tiny, no frills state machine for Go

#50

Post by spicybright »

packetslave wrote: post #33
earthboundkid wrote: post #26

A state machine should have more than states. It also needs actions which cause transitions. The API should be about writing out which new state an action causes given a base state. Eg you have a modal with a button and it can be clicked or dismissed. In the open state, click and dismiss cause close, and in the closed state, click causes open. Anyway, the whole thing is only valuable once you have actions.

Commenters like you are why people don't share thing. Why make something available for free when someone like you is just going to come along and shit on it?

If you post your project on a public forum with a comment section, you should expect some people to be critical and suggest things, no matter what it is or how much it costs.

Perhaps the real issue is commenters like GP is why YOU don't share things?

Post reply on HN