Cedric, hello. Thanks for these further notes. Following your remarks and Chris's, I've logged this as a bug at <http://dev.clojure.org/jira/browse/CLJ-911>
I've added a few further comments below. On 16 Jan 2012, at 17:56, Cedric Greevey wrote: > A proper clojure finalizer would > have to be (finalize [] (try (do something) (finally (proxy-super > finalize)))). Though finalizers are icky, they probably *should* be > allowed, for completeness' sake. I'm inclined to regard this as a bug, > unless someone posts with a convincing explanation why clojure proxies > having nontrivial finalizers would be a very bad idea. I was about to disagree with you about finalizers, but on reflection I won't. I'm in Clojure, having stumbled over the border from Racket, which is a lot more comfortable with finalizers, via notions of custodians and wills. In the application I'm working on, I believe I can eventually make (JVM) finalizers robust, and in this case there aren't the resource-exhaustion problems that convincingly argue against the strategy in general; but since the JLS goes out of its way to make only the most evasive guarantees about finalizer behaviour, I think one can say that finalizers just aren't JVM-idiomatic, matteradamn what the brackets look like, and conclude that I should find another pattern. I feel a with-* macro coming on.... > As I understand it, there are two pieces to the proxy. > > One is a subclass of the specified base class and/or interface(s). The > proxy object is of this class; as you saw, your HashMap derived proxy > had an (ancestors (.getClass x)) that contained HashMap among other > things. > > The other component is a map of clojure function objects. The proxy > object's methods just look things up in this map and invoke them. The > map can be updated later, with update-proxy, and the existing proxy > object's methods will change behavior correspondingly, something not > otherwise possible. That's why there's a default call-super > implementation of every method, even if you don't override it when you > first call proxy, because if there wasn't, you couldn't later override > it with update-proxy. This is very valuable background. > Anything called by a Java library in a tight loop via an interface, > though, you might prefer reify for. Reify has some other features, > too, and probably some other limitations. Though there's a sizable > overlap region where either can be used with acceptable results. It's not clear from the docs what 'reify' returns, but it seems to accept only protocols, interfaces or java.lang.Object. It does appear therefore that the only way of extending (in JVM terms) a class is through bells-and-whistles-and-gongs gen-class. Best wishes, to all, Norman -- Norman Gray : http://nxg.me.uk -- 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
