I don't think there is a general answer to this fundamental impedance mismatch, but you might want to look at the implementation of clojure.core/bean: https://github.com/clojure/clojure/blob/master/src/clj/clojure/core_proxy.clj#L372
That doesn't provide a deep view but it's a start for approaches #2 and #3 above. Also be wary of this bug: http://dev.clojure.org/jira/browse/CLJ-978 On Sat, Apr 5, 2014 at 4:10 AM, David Koontz <da...@koontzfamily.org> wrote: > I am very new to Clojure so please forgive me if there is an obvious > answer that I have missed. I'm trying to understand the effect of interop > with Java objects, specifically on the polluting nature of non-values in a > system. If I need to interop with a Java library, and that library will > have mutable objects, how do I shield the rest of my program from that? I > can think of a few solutions but they all seem terrible. > > 1. Copy all the data from the mutable Java object to a Clojure structure > that is a value. This seems incredibly wasteful and in my case probably > totally unmanageable due to the GC pressure it would create (I'm working on > a game with lots of rapidly mutating Java objects). > > 2. Create a value-like wrapper that provides a read only interface. This > doesn't really cause a memory issue, but now you have a "value'ish" thing > floating around that while not modifiable by you can up and change at any > moment. > > 3. Create a wrapper that memoizes data into true values but only as it's > accessed. In my case I have an update window that demarcates time into > discreet slices. At the end of the frame I could indicate to my "value" > that the underlying Java object can no longer be trusted to be the same so > all future attempts to access non-memoized values should fail. This works > as long as you access the same fields/methods off the Java object down the > road. > > Of course all of these solutions have issues with object graphs and > needing to walk the whole graph to fully convert it into a value. So is it > worth trying to do anything along this path or is this a fool's errand and > I should find some other code organization way to run caution tape all over > the place shouting "careful here, this is dangerous highly volitile stuff!"? > > -- > 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. > -- 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.
