On May 18, 2009, at 9:47, Mark Engelberg wrote: > On Sun, May 17, 2009 at 11:48 PM, Konrad Hinsen > <konrad.hin...@laposte.net> wrote: >> It's the approach of "cloning and >> mutating" something that smells of "quick and dirty", although I >> agree it is quite convenient in the prototyping phase. > > I disagree that incremental extension of a module is a "quick and > dirty" prototyping technique, and would argue that this is a > fundamentally desirable feature.
It's pretty much what is called "monkey patching", with the difference that you monkey-patch a clone instead of the original object. I don't think there is universal agreement about its desirability. I have done it as well (in Python), and while it had mostly worked fine, I have regretted it in a few situations, after long hours of debugging. It is definitely a risky technique, as it requires a good understanding of the original code, plus regular verification that updated versions of that code still behave as they did before. > Clearly this is not an acceptable solution, because then he won't > benefit from any future updates I make to themodule. He can't use > the "load" trick, all because of the (ns clojure.contrib.math) > declaration at the top of the file. He can still write a variant of load that redefines to ns macro in clojure.core, loads the file, and restores clojure.core/ns to its original value. In fact, nothing prevents you (or anyone else) to provide such a variant of load as a library function to make this easier. The only condition is to have access to the source code; if all you have is precompiled class files, the source code is gone and load won't work any more. > Based on this discussion, it sounds like I (and all library authors) > should have provided all of my math functions in one file (say, > math_functions.clj), and then had a separate file (math.clj) > containing: I wouldn't really want to encourage people to monkey-patch my libraries (and then complain to me if it doesn't work). However, there is the more interesting question of how to write a library that is meant to be extended/modified in a well-defined way. In OO, one would encourage subclassing for overriding some methods. As far as I know, there is no single equally universal technique for functional programming. > If all library authors want to start doing this, I guess that's one > solution. I'm just hoping there is a better way. I don't think there is any other way at the namespace level. Once a namespace is evaluated, all functions are compiled and all references are resolved. 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 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 -~----------~----~----~----~------~----~------~--~---
