> > Yes, but "create a static final member in the class I'm generating > bytecode for, stuff the object in that static member, and embed a > reference to the static member here" seems like a sensible thing for > it to do. >
That's easy for simple types like java.util.Date, but how could it work for all arbitrary objects? Those objects may contain pointers to other objects. How would you stuff a java.util.TreeMap into a static field -- perform a deep copy of the entire structure? There's no standard interface for deep copy, or even an easily-agreed-upon notion of what deep copy IS. Java serialization runs into the same problems. Where do you stop? You have objects with volatile fields or pointers to system resources like filehandles. How would you stuff a java.io.InputStream into a static field? That's not to say you couldn't write Clojure functions to embed serialized data in private static final Date blah = somedate; > You can't do that, even in Java. The constant pool<http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html#9597>in a compiled class can only contain primitives, Strings, and names. Where does `somedate` come from? You have to provide code to construct a java.util.Date, which javac will add to the static initializer block of the class. Clojure does essentially the same thing with `print-dup`. The deeper issue here is that JVM bytecode is fundamentally static: it's not allowed to contain references to objects that only exist at runtime. In languages that have a built-in concept of a "runtime image," like Smalltalk or some Lisps, the line between static code and runtime data is blurred. -Stuart Sierra clojure.com -- 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
