Allow enums/ types other than strings about snowstate

[sohomsahaun]

1. A common solution to that is macro-ing the state names. It works as well as an enum in this case.
2. I really dislike this sort of comparison/ arithmetic operations with enums. This makes the code harder to follow and prone to errors as you expand. I highly disagree on this being more maintainable than doing:

states_to_check = ["idle", "walk", "skid_to_stop"];
if (array_find_index(states_to_check, fsm.get_current_state()) != -1) {
  // Do stuff
}

OR, you can make use of SnowState's inheritance! (if possible)

fsm.add("state_to_check");
fsm.add_child("state_to_check", "idle", { /* Behavior */ });
fsm.add_child("state_to_check", "walk", { /* Behavior */ });
fsm.add_child("state_to_check", "skid_to_stop", { /* Behavior */ });

if (fsm.state_is("state_to_check")) {
  // Do stuff
}

[theinfamousmrmeow]

hey friend are you open to accepting PRs on this one?

[sohomsahaun]

I'm still deciding on this feature - and I'm leaned towards not allowing anything other than strings.
What benefits do you think enums bring? (You can also stringify enum entries and pass them)

[theinfamousmrmeow]

Hi!

So the main use cases I've run into are:

1. Just basic error prevention by taking advantage of the code completion in GMS2. Easier to make sure everyone is using the right state names if they're conveniently in an enum. This can be addressed as you say by stringifying them though!
2. The second is doing comparisons and operations on the integer the Enum points to:
   (if fsm.get_current_state() <= E_STATES.ACCEPT_INPUTS)
   Is much easier and more maintainable than having to chain comparisons:
   (if fsm.state_is("walk") || fsm.state_is(""idle") || fsm.state_is("skid_to_stop")
   You can also potentially add or substract to the enum for varying degrees of intensity or for alternate forms etc.

[theinfamousmrmeow]

We discussed on Discord, thanks :D Posting this in case someone else is interested in the question:

I'm convinced that the advantages of readability are worth losing out on being able to do math on the enum integer, and input validation can be handled other ways as you said. The inheritance paradigm here is very strong, missed that.
There's a second argument about under the hood performance using enums and arrays rather than structs, but that would require new plumbing and is outside the scope of this original feature request.

[sohomsahaun]

The other solution requires a rewrite (of most of SnowState) and I am considering it.