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

Reply via email to