On Mon, May 18, 2009 at 2:16 AM, Meikel Brandmeyer <m...@kotka.de> wrote: > If that is true, you should maybe consider some glue. > > /- Analysis > Glue -- Solve > \- Create > > The Glue part combines/uses the different modules. There you > could change parameters easily with binding, swap in another > analysis module, whatever...
OK, so let's talk more about what this glue code should look like. I've been lumping this problem together with the other, because in my mind they are related, but perhaps there is a clean way to glue together modules without the incremental extension technique. Let's say I've got a namespace for my generate functions, a namespace for my solve functions, a namespace for my analysis functions, and a namespace for my filter functions. Now, the generator uses the solve functions, e.g., generator/generate-puzzle will somewhere call solve/solve-puzzle So presumably, at the top of generator.clj, I have (ns generator (:require solve)) Similarly, generator also has dependencies on functions in analysis and filter namespaces. Furthermore, some of the filter functions have dependencies on the analysis functions, and so on. In other words, assume that most of the modules have dependencies on each other. However, let's say my solve-puzzle function isn't working as effectively as I'd like. It solves the puzzle in a brute force way, and I realize I'd like to try another version that solves the puzzle more like the way a human would solve it. So, I want to swap it out with a new solve module, i.e., a new namespace, and have all the other namespaces point to it. Maybe even make it easy to swap back and forth at runtime so I can compare the two approaches. So how to do this? As far as I can tell, these various modules are all "hard-linked" to point at one another, and I don't see how to make this linkage more dynamic. To change one file, I'd have to create new versions of ALL the files. It would be great if each file could store a variable for what namespace it needs to use to get at the other functions. For example, the generator has a variable that points at the solver namespace, and accesses the solver functions through that variable. Then, you could have one master file that loads the particular versions of the modules you want, and links them to one another. But I really don't see how such glue could be written. Any suggestions? On the other hand, it's pretty straightforward to achieve this when you use "objects" for your modules. To be clear, I'm *not* a fan of using OO to create bundled data structures with elaborate chains of inheritance, but what I'm starting to realize is that in OO, you get a pretty decent "module" system for free, using the same concepts that OO programmers are already familiar with. In the absence of OO, the details of the module system become much more important because modularity becomes an orthogonal issue that is not really covered by the other aspects of the language (thus all the research papers on the topic of modules in functional programming languages). --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
