When one needs to get clojure data passed around over some string carrying pipe, one would need to override the print-dup/print-method methods for non-roundtrippable objects like java.io.File. This modifies the public and functionally global namespace, which is not good practice. A recommended approach would be to define one's own print function like so
http://stackoverflow.com/questions/10005102/how-to-override-println-behavior-for-reference-types/10013247#10013247 However, this approach is leaky. Though in some other objects and it fails again. One might then provide default methods or Object methods that delegate back to print-method. This, however, doesn't work for collections since collections delegate only to clojure.core print methods and if you see a File in there, it won't use your methods. Therefore, coming back, the only way to make a truly non global modifying but complete printer, one would need to basically write their own version of clojure/src/clj/clojure/core_print.clj. A much larger task. A couple of observations here: 1. It seems useful to be able to copy an existing multimethod (and its implementations) into another namespaced multimethod. Then one should be able to make incremental changes. This is analogous to copying someone's hashmap, and then using clojure.core/update-in to modify it for your use. The other person's hashmap is unmodified. 2. When reading in the strings that contain forms, we rely on the *data-readers* hashmap, which is a map from symbols to fns. One limitation with this approach is we can't match patterns, only concrete symbols. So phrased differently, currently it's not possible to call a fn on anything of the pattern #my.personal.namespace/<whatever else fits here> "clojure data literals", I realize that we need to be careful of what the reader can do in terms of parsing, but I feel it needs to be more flexible. An alternative approach would be to have the reader pass the valid symbol to a rebindable dispatch function. This may be too powerful, however, since parsing classnames and reserved tags wouldn't compose well in this situation. To perhaps strike a balance, one compromise would be to do this only for full qualified symbols. This way different people's tags and their implementations don't step on each other. Yet another solution (which I am starting to like more as a write and is really more a convention then an implementation), would be to treat the tags conceptually not as a symbol, but as a namespace reference. Then one could print additional data (in the data literal part) that one could then dispatch off of. This has the advantage of not requiring modifications to the current implementation of tagged literals. I haven't seen many examples of tagged literals on the mailing list, but this requires some agreement about how we name our tags so that we don't step on each other. So instead of #my.namespace/someobject ["blah blah"] we have #my.namespace [:someobject "blah blah"] Thoughts? -- 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
