I think the type of data structures you use will depend on how you
need to access the data. For a GUI it's nice to be able to lookup a
unit by ID, for example when it's clicked on, so I would probably
store all units in a map by ID, and then have a separate location to
ID map as you described. They could be together in an atom, or
separate in refs if you want more concurrency. Using immutable data
structures you just have to get used to creating new versions every
time you modify data, but using functions like update-in and assoc-in
you can probably get at your data pretty easily. Create a couple
functions to handle moving location, updating properties, etc., and
you might find that it isn't ugliness that you are hiding :-)
On Jun 1, 11:12 am, yair <yair....@gmail.com> wrote:
> Hi,
>
> I am writing a little board game in clojure, mostly to educate myself
> about how to organise and implement a larger-scale program than my
> usual tiny little snippets. The program has a central data structure
> of units which are placed on a map. Each unit has some information
> like a name, movement points left, strength, and it's current location
> on a 2D hex-map. Units are implemented as maps, so a unit can look
> like
> {:name "Fighter 1" :movement [3 12] :strength [4 4] :location [1 2]}.
> I hold the units in a map from locations to the sequence of units on
> that location. There is an atom that holds this map, so any change to
> the data means basically creating a new map and resetting the atom.
>
> So, when a unit moves, for example, I need to remove it from the
> sequence at it's old location, and add it to the sequence in the new
> location, and change it's location value and it's movement points
> value. In Java, this would be pretty straightforward. But with
> immutable data structures, it is quite clunky. I have thought of some
> alternatives:
>
> 1. Continue doing what I already am, perhaps write some functions that
> hide the "ugliness" and get on with it.
> 2. Give each unit object an ID and hold a map from location to unit
> IDs and from ID to the actual unit object, but that is kinda like
> making immutable objects all over again.
> 3. Using mutable data, like Java's lists, maps, etc. This is of
> course extremely ugly and I would have to be strongly persuaded to go
> down this route.
>
> So, does anyone have any better ideas or is this type of program
> always going to have some impedance with FP and immutable data?
>
> Thanks
--
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
