On 14/06/12 10:01, nicolas.o...@gmail.com wrote:
There should not be any atom in this. The function would be more reusable if it take a board and return a board without changing any atom. (You will still be to express the atom change around it but you could also use to try and build a tree without undoing anything.)
Yes you are right nicolas...I really don't need to reset! the atom inside 'move'...It has been addressed...
I don't think this approach is extensible enough. You will want to implement more games later. So maybe a good thing is to use protocols or multimethods to represent game rules. The atoms should disappear until later. (You are building a library of moves and rules, there is no notion of state in that. Only when you use it for playing a game on a GUI you will need a state)
I don't want to involve multi-methods in this particular project for performance reasons...I do get your point but current-items is only fetching the atom or the derefed atom from a game...more game means adding a clause so it fetches the appropriate pieces...game rules will be implemented in core.logic it has nothing to do with this fn. I do agree I will only need the atom when playing an actual game though...
Jim -- 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
