Hi, I have various general questions about how one can perform simple and flexible graph query/update.
If we start by a structure being nested maps then I know about get-in/update-in/assoc-in. The common point about these functions is that they all take a path to where the data is in the superstructure and that this path is only a sequence of keys, which may or not be symbols. 1) What happens when one layer of this superstructure is not a map but a sequence? For the sake of the argument, we can keep the discussion simple by only arguing about the vector case. Typically instead of { :key1 { :key2 val }} we now have { :key1 [{ :key2 val }]} Of course, one can perform get/update/assoc using map/reduce. However, it means that the code using this superstructure is taking a hit on complexity/maintenance each time a non-map layer must be crossed. Of course, the simplicity/beauty of the current implementation is that a path can point to at most one target substructure/value. Is there a way to do something similar with a more general definition of a path? One would assume that it is something that might be handled by xml/html modification libraries (think xpath or css selector) but this problem is more general and not domain specific. Is there a clean library that handle that case without being tied to html/xml? 2) How to deal with more general superstructure like a graph? One could build an immutable graph but I don't believe it is something that can be done by nesting immutable maps and vectors. One solution to deal with 'entity'--'entity' relationships is for one of the member to own only an identifier to get the other member from another reference structure. (from the basic OM tutorial:) {:people [{:type :student :first "Ben" :last "Bitdiddle"} {:type :professor :first "Gerald" :last "Sussman" :classes [:6001 :6946]}] :classes {:6001 "The Structure and Interpretation of Computer Programs" :6946 "The Structure and Interpretation of Classical Mechanics" :1806 "Linear Algebra"}} It is, of course, again, manually possible to get/update/assoc using map/reduce. But then, again, this is the same problematic as with the first question : each time a relation needs to be crossed, the code using this superstructure is taking a hit on complexity/maintenance. How do you usually deal with this problematic? For both question 1) and 2), a more appropriate data structure might be the answer like a graph/semantic-like store (Datomic or something else). The questions are about intermediary solutions which would be less heavier. 3) How does Demeter lives with graph traversal? This law is often heard in the OOP world but it is a bit more general than that. When a long path on a superstructure is specified then if one intermediary layer is introduced later, all hardcoded paths will be broken ie in multiple locations in the code base. One would like to store local structure knowledge in a single place. How do you usually deal with this problematic? I have yet to take a serious look at lenses and their composition, they are probably an element of answer, but they are more often seen in more statically typed langage. Thanks for any feedback. Bertrand -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.