2010/6/3 Rich Hickey <richhic...@gmail.com>
>
>
> 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.
>
Something like being able to declare a "black list" of symbols (e.g. #{
#"java\..*", #"clojure\.core\..*"} ) for which no implementation may be
provided without e.g. raising a warning ?
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.
>
>
May I add this policy concerning Clojure protocols (as well as the rule "one
must only extend a protocol to a type if he owns either the type or the
protocol. If one breaks the rule, one should be prepared to withdraw should
the implementor of either provide a definition") to the assembla Wiki page
on best practices / conventions ?
--
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
