4 ms·
apache hbase is full of awful state machine code implemented in a slight variant of "the wrong way" described in this paper. it is 100% unreadable spaghetti. he
by jeffffff 6y ago
apache hbase is full of awful state machine code implemented in a slight variant of "the wrong way" described in this paper. it is 100% unreadable spaghetti. here's one example: http://archive.cloudera.com/cdh5/cdh/5/hbase/xref/org/apache/hadoop/hbase/master/procedure/ServerCrashProcedure.html#177 http://archive.cloudera.com/cdh5/cdh/5/hbase/xref/org/apache...
not sure the goto approach would much better but this approach ends up just being a poor reinvention of goto in java
- woofie11 6y agoThe GOTO approach is better, so long as the FSM is abstracted away. An FSM implemented as GOTOs is great. An FSM + state internals implemented with GOTOs is a disaster. You don't want to mix the FSM with the internals of the states. For example: STATE_1: result = state1.action(); if result == A THEN GOTO STATE_2 if result == B THEN GOTO STATE_7 Is okay. Complex internal logic is not: STATE_1: [ton of actions and logic] if [ton of logic] THEN GOTO STATE_2 if [ton of logic] THEN GOTO STATE_7 If your states are more complex than that, it's a mess. Or if your language supports it: STATE_1: NEXT_STATE = state1.action() GOTO NEXT_STATE Again, modern language support is horrible for this sort of thing. You can go one step up and make a generic FSM, with e.g. a Python dictionary of functions which return future states: while True: state = STATES[state.action()]