The problem here is that you are presuming that a protocol function "bar" is a behavior of the types it is extended to. Invert that: "bar" is its own function, and the types come to it, not the other way around. If you explicitly replace "bar" with a new function (which redeclaring the protocol does), then call the new function, you will get ... the new function.
Types don't have behaviors. Behaviors have (a dynamic association with) types. The fact that you can declare the behavior inline on a type is a convenience: The controlling entity is the function, not the type. There is a real practical issue here, but it is more modest than what you describe. You can add a new default implementation anytime you want, without causing any problems with existing implementations. It is redefining the *protocol* that causes a need to revisit other code. Tools could indeed help with this. I realize that this is unfamiliar for people (including myself) coming from OO, but I want to emphasize that your confusion is not about an ancillary point -- it is central to how protocols work. Hope this helps, Stu Stuart Halloway Clojure/core http://clojure.com > Perhaps I should have explained why I think 20 should be the right > answer. > > This is based on my expectation that once I've compiled a file the > behavior of records or types defined in that file will not change > (unless I re-bind functions called by the record or type). The above > behavior violates this principle in a very natural use case where I > add or recompile a default implementation of a protocol located in a > separate file from a record implementing that protocol. > > On a more practical level the current behavior means I have to > explicitly recompile multiple files when I change a line in one file, > which is somewhat inconvenient (perhaps there should be a way to auto- > detect this situation and have the Clojure compiler recompile the > appropriate file???). If I forget to do this then the code will behave > in unpredictable ways because I've suddenly replaced the non-default > implementations with a new default implementation. > > On Aug 26, 7:08 am, MikeM <michael.messini...@invista.com> wrote: >> I may have misunderstood what I've read about protocols, so please set >> me straight if the following is wrong - >> >> On Aug 25, 11:08 pm, Stuart Halloway <stuart.hallo...@gmail.com> >> wrote:> I think the current behavior follows the principle of least surprise: >> >>> (1) bar is a function, in whatever namespace the protocol Foo is defined in >> >> But bar is not a single function. Multiple bars can coexist in some >> sense, right? Otherwise there's no polymorphism? >> >>> (2) you redefine bar (perhaps by reloading the file Foo is in) >> >> I don't see this as bar being re-defined, rather bar is defined for >> fooed, then defined for Object >> >>> (3) you call bar and get the new behavior >> >> It seems that the dispatch mechanism for bar is preferring Object's >> bar rather than user.fooed's bar. This is not what I expected. So >> maybe the right way to think about this is that protocols don't pay >> attention to class hierarchy when dispatching: user.fooed is an >> Object, and bar was defined for Object after bar was defined for >> user.fooed, so Object's bar is selected? > > -- > 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 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
