On 3 Jun 2010, at 13:56, Laurent PETIT 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 ?
The difference is that with the Clojure approach, the type definition
and the protocol definition are separate and can well live in
different namespaces. Extending a protocol to a type is safe if your
code "owns" at least one of the two. With the Ruby or Python approach
of dynamically modifiable classes, the class definition defines both
the data and the protocol, all in one, so there is only one "owner"
and everyone else messing around with it will be bothered by sleepless
nights ;-)
So it is fair to say that Clojure has a safe solution for a much wider
range of situations, even though, as you noted, there is still the
possibility of interfering protocol implementations.
Konrad.
--
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
