3 ms·
> struct MyAlgorithm This is a particularly bad name for your situation. An algorithm is not an object. Why not "my_state"?
by enriquto 6y ago
> struct MyAlgorithm
This is a particularly bad name for your situation. An algorithm is not an object. Why not "my_state"?
- jcelerier 6y ago> Why not "my_state"? because it's a HN post and not real code ? And it contains the code of the algorithm, in the operator()... function. So my_state would only tell half the story. When I use it, what do you think makes more sense : GameExecutionAlgorithm<TensorflowGameStrategy> game_algo; next_positions = game_algo(...); or GameExecutionState<TensorflowGameStrategy> game_state; next_positions = game_state(...); > An algorithm is not an object. That is however completely conflating two different things. By that line of reasoning you couldn't write algorithms in e.g. Java or Smalltalk because there everything is an object and "an algorithm is not an object" => "there are no algorithms in Java / Smalltalk". Objects are just a syntax construct without attached meaning (or, if you did attach one at some point by reading some 1980 OOP book, please detach from it as that only causes confusion).
- enriquto 6y ago>When I use it, what do you think makes more sense : > (...) None of your examples make any sense to me. Why not name it simply "game"?
- msclrhd 6y agoWhat about something like "in_order_traversal", which is an algorithm and you need to keep track of the traversed stack. You could either write it with functions in which case you would need to pass the stack as a parameter and have a constructor/initial state version of the function that passes the stack to the main function, or have a functor/function class that keeps the stack internally.
- jcelerier 6y agolikely "game" would be something that would be about the whole game, including graphics, sounds, etc.
- bigbizisverywyz 6y agoSo there are 3 hard problems in programming. 1. Naming things, and .. I forget what the other one is.