Interesting approach. I'll keep it in mind, but for this particular project I actually have to have mutable objects - both parents and children must be modifyable. Also I really want to see them as collections: closures where used everywhere in the previous version of program, and it was very hard to test them in REPL, since you cannot see actual data, stored in closure. Nevertheless, I agree with you that some kind of combining collections and closures is the best approach for pure functional applications.
On Oct 14, 2:33 am, meb <meba...@gmail.com> wrote: > Instead of using a ref, you might consider using a closure, which > seems a little more functional. > > So every child would simply store a function that when called would > return the map of the parent, map you capture using a closure. This > would also reduce your printing problems because functions just print > their classname, and you would know that the function brings you back > to the parent. > > I did this for a Neo4j wrapper I wrote to idiomatically represent > traversing webs and trees. > > Would that help anyway? Then you wouldn't have to worry about messing > with redefining prints or using alters. The thunk would be created as > part of the process. > > Mark > > On Oct 13, 4:21 pm, andrei <andrei.zhabin...@gmail.com> wrote: > > > That works, thanks! > > > Yeah, I understand that it is not the best data structure to use. The > > task is to create a tree, and it is needed to get all children and all > > parents of specified node in this tree in a constant time. So, I > > cannot see another way to do it except storing refs both from parents > > to children and from children to parents. > > > On Oct 14, 12:40 am, Laurent PETIT <laurent.pe...@gmail.com> wrote: > > > > You can add a :type metadata to your maps, and this can be catched by the > > > (type) method of multimethods. > > > > But if you have parent -> child -> parent -> child ... relationships, I > > > guess that you're building a tree made of mixins of maps and refs to maps > > > ... and indeed this should bell some rings in your head if you haven't > > > already carefully balanced alternative choices ... > > > > 2010/10/13 andrei <andrei.zhabin...@gmail.com> > > > > > How can I override print-method for a map, defined with defstruct? > > > > > I have to create object hierarchy: one map is a parent for another, > > > > i.e. it holds link to a child, and another is a child for the first > > > > one, i.e. holds link to a parent. When I try to print it, I get > > > > StackOverflowError since printer tries recursively print objects: > > > > > parent -> child -> parent -> child -> .... > > > > > The best solution I see is to override print-method or str, so the > > > > printing will go normally. I found this topic: > > > > >http://groups.google.com/group/clojure/browse_thread/thread/4a675222f... > > > > > which shows how to override print-method for objects defined by > > > > deftype, but is there a way to do same trick for maps? Maybe it is > > > > possible to add some special tag to object's meta? Or to redefine > > > > print-method in the only namespace? > > > > > Or maybe I'm just looking at the wrong direction? > > > > > -- > > > > 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<clojure%2bunsubscr...@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 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
