On Wed, Feb 2, 2011 at 18:49, Alex Osborne <a...@meshy.org> wrote: > 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. > > Ahh, as proven here:
example> (defprotocol Extended (foo [this])) Extended example> (defrecord Extender []) example.Extender example> (extend-protocol Extended Extender (foo [this] "first")) nil example> (def x (Extender.)) #'example/x example> (foo x) "first" example> (defrecord Extender [a]) example.Extender example> (extend-protocol Extended Extender (foo [this] (:a this))) nil example> (foo x) "first" example> (foo (Extender. "second")) "second" This is clearly quite cool and I'm now interested in more! > > 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. > > Thanks for asking me to step back and think about it - you're right - it is clear to me now - this caught me out as a result of repl based work and stray references. > -- > 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<clojure%2bunsubscr...@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 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
