André Thieme wrote: > How can we handle this situation? > Is it possible to implement a function “deep-deref” which works > as blindingly fast as deref does? > I find this very important, and this is of great practical relevance > for me. Please share your ideas
Hi André, I had a similar issue with an application I wrote a while back. The initial structure was simple: a grid-based map, containing a number of entities, each entity having a name, an owner, dimensions, etc. The map was behind a ref, and the entities were initially refs themselves, embedded within the map structure. Then I realised that it was difficult to know with certainty what was in the deref'd map. It kind of struck me then that I was thinking about the problem incorrectly. My object-oriented hat made me want to have the map and entities as separate things, each in charge of its own state. When I re-wrote the code so that the entities were themselves an immutable part of an immutable map, and that changes to entities resulted in an *entirely new map*, those problems went away. All the various interactions with the UI and with the network updated the map and entities transactionally, with a new, consistent map after each alteration. What a relief that was! In your case, adding someone to a friend list should result in what is conceptually a completely new database, that shares almost all of its structure with its predecessor. This top-level structure can sit behind a ref, with immutable person structs as constituent parts. This makes proper use of immutability and negates the need for a deep deref. That's just my experience. I'd be interested to know if anyone has an honest need for refs within refs (especially in a larger system). Cheers, Danny. -- 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