On 14 Nov., 20:32, Danny Woods <dannywo...@gmail.com> wrote:
> 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.
Danny, could you maybe hack up a possible very simple example of what
you mean?
I am not sure how complete my understanding of what you said is.
> 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).
The idea behind my posting is a in-ram db system.
I don‘t want to use a relational db.
Now I have many objects, be it defstructs or deftypes. Those things
need
to be changable. And other objects must be able to reference them.
In the example I made up Tina has the friend Karl.
I can not simply store a copy of the Karl person in Tinas :friends
slot,
because when Karl gets one year older, then I don‘t want to go through
all persons, looking for Karls, and have their age updated.
Instead it is preferred to have
(defn update-age [#^String person new-age]
(dosync
(alter (get @*persons* person) assoc :age new-age)))
When we then (update-age "Karl" 25), then the Karl in Tinas :friends
slot will also be 25.
And each object needs to live in at least one index. In my example
this index is called *persons* and maps from the name to a person
instance.
There can be other indexes, for example *age-to-persons*, and when we
look up there who is 42 years old, then we will get a set of person
instances who are older.
These indexes need to be refs also, because we constantly want to put
new objects in there or delete them. So, refs in refs are really
interesting when you want to have your own in-ram db system.
--
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
