On Apr 20, 9:43 am, Craig Ching <craigch...@gmail.com> wrote: > Thanks for your input, I appreciate it. > > On Friday, April 20, 2012 10:16:51 AM UTC-5, kurtharriger wrote: > > > And you just need to keep the resulting state, no need to reapply the > > moves. > > Your main method might use a reduce or loop recur. > > > (loop [game (new-game)] > > (if-not (complete? game) > > (recur (make-random-move game))) > > The problem I have with this is that it does encapsulate game state > completely, including input (the moves), but I want to just encapsulate > board state. Imagine that the moves come from an external source, i.e. the > web, my game state can't be stuck down in a function somewhere, the move is > sent from the web, the game state is retrieved from somewhere (a session? > a database?), and updated with the incoming move. I wasn't clear in > stating my problem, but I want to decouple game state and board state for > this reason. And because that's where I'm headed, it might make sense for > me to approach this using atoms as others have suggested. > > I appreciate the different perspectives though, it's helping me understand!
Game state does not have to be a map, it could be any datastructure you want, perhaps a protocol that is implemented by a concrete class in another JVM language. However, I avoid encapsulation unless there is a compelling reason reason to add it. More often then not the result of encapsulation is that the entire library of useful functions like map, reduce, get-in, update-in, etc... are no longer useable with this custom data structure. It is also not strictly required that all your functions be pure, you could load or save game state to a database or external service as necessary. There are very few applications that are strictly pure. However, it is recommended that you make as much of your program pure as possible. If each time you made a game move the state was written to a database then you might have difficulty trying to run multiple solver strategies in parallel as these side-effects would continuously clobber the others database state. The general idea is that pure functions are easily composed and easy to test, so use them whenever possible. Impure functions that write to external services are often much more difficult to compose and test, so keep them as small as possible. Think twice about calling an impure function from a pure function as this makes it impure... main will almost certainly be impure, but that does not mean that everything else also needs to be impure. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
