On Jun 3, 9:28 am, Laurent PETIT <laurent.pe...@gmail.com> wrote: > Hi, > > 2010/6/3 Christophe Grand <christo...@cgrand.net> > > > > > > > On Thu, Jun 3, 2010 at 1:56 PM, Laurent PETIT <laurent.pe...@gmail.com> > > wrote: > > > If I understand things well, one problem with ruby monkey patching is > > that > > > if a library I use opens a class C and adds a method whose signature is M > > to > > > it, and if in my own code I also open the same class C and add a method > > > whose signature is M to it, then the library may break because it will > > call > > > my implementation of M, not the librarie's original one. > > > > Now to clojure. I can see the same problem occur, while the article's > > author > > > claims that in clojure there's (almost) no problem anymore. > > > If several libraries, including my program, redefine blindlessly a > > protocol > > > implementation for the same type, then the "last to speak" wins. > > > So isn't the problem basically the same ? > > > my 2 cents: > > > The surface of the problem is reduced because of namespacing: two > > different "fold" methods (with different semantics) from two protocols > > won't clash. > > Of course. I was not thinking about that. I was talking about working on the > same protocol. > > Here is the scenario I have in mind: clojure 1.3 ships in december with > loooots of protocols for the whole set of abstractions currently implemented > as interfaces. > > A bunch of developers all over the place start adding implementations for > these protocols for types not covered by clojure itself .... > > > Plus if there are two extensions of the same protocol to > > the same type, they should be rather equivalent since they satisfies > > the same semantics. > > ... granted, the more specific the semantic will be, the less different the > implementations should behave. > > So back to my scenario: lots of people adding protocol impls for lots of > "common java types" : new implementations each time, copied implementations > some other time. Of course some implementations will be buggy the first time > they are delivered. Depending on N libraries each providing their own > implem. in a particular version could lead, depending on the order the > libraries are loaded in the environment, in having sometimes a buggy > version, sometimes an "almost correct version". > > > > > I think one must only extend a protocol to a type if he owns either > > the type or the protocol. > > The general example here is java.lang.String. Nobody owns it but oracle/sun > (and arguably clojure itself). People will want to reimplement some clojure > protocols on it, interpreting the String content in a bunch of exotic ways > :). > > But I understand the rule : "extend with great care if you neither own the > protocol nor the type".
Yes, and be prepared to withdraw should the implementor of either provide a definition. Actually, I think the biggest issue will be people extend protocols to types for which they don't make sense, e.g. for which the protocol authored considered but rejected an implementation due to a semantic mismatch. No extension will be there (by design), and people without sufficient understanding/skills might fill the void with broken ideas. I don't have a means to prevent this at present, but I'd like to suggest this policy moving forward: If a protocol comes with Clojure itself, avoid extending it to types you don't own, especially e.g. java.lang.String and other core Java interfaces. Rest assured if a protocol should extend to it, it will, else lobby for it. Rich -- 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
