Michael Ossareh <ossa...@gmail.com> writes: > You'll notice in the map returned after the second (extend-protocol) > that :impls has example.Extender1 listed twice. I assume this is > because they're different records, though the fact > that they share the same name is confusing (hence the example of the > exception being thrown).
> A few questions: > - Is this expected behaviour? > - If so, why? It feels "odd" to have two classes of the same name (type > even?) act differently This has to be the case as you might have instances of the old version of the class hanging around, which you could call protocol functions on. The JVM doesn't let you modify existing classes in place (for obvious reasons: what is it supposed to do if you changed the primitive type of a field). All you can do is load a new one (possibly with the same name) and then create some new instances with that new class. > In the other examples of extend-protocol being used > (compojure.response/Renderable) types far less likely to be redefined > are being used, so perhaps this is only to be used with types that > change less? If that is the case then how does one achieve what I'm > trying to do; extend Renderable to support my own types being passed > to it without Renderable acting on my previous > types? Could you rephrase this? I'm not sure I understand what you're trying to achieve. The dynamic redefinition features are supposed to be used for solely as handy hack for interactive development. So if your environment gets messed up too much you can just reload everything in a fresh JVM. In a "finished" program redefinition should never occur. -- 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
