2010/2/8 Sean Devlin <francoisdev...@gmail.com>: > Perhaps I have an incomplete grasp of the problem domain, but wouldn't > a map stored in a ref let you do this?
I don't understand. > > On Feb 8, 9:12 am, Laurent PETIT <laurent.pe...@gmail.com> wrote: >> 2010/2/8 Chouser <chou...@gmail.com>: >> >> >> >> > On Mon, Feb 8, 2010 at 5:29 AM, Laurent PETIT <laurent.pe...@gmail.com> >> > wrote: >> >> Hello, >> >> >> Did anybody create a functionally equivalent clojure version of >> >> so-called Groovy Builders ? >> >> (http://groovy.codehaus.org/Builders) >> >> >> Not that it should be too difficult to come up with an equivalent, and >> >> also not that it would seem to you that it is interesting to do so >> >> given the power of clojure, but ... >> >> >> ... a friend of mine is investigating into groovy because he wants to >> >> leverage groovy builders power (does not want to write his application >> >> in groovy, just the builders parts). >> >> >> ... so I said to him: take a look at clojure, it really shines at >> >> mixing data and code, has very good support for writing data structure >> >> literals, and with the power of its macro system, you have unlimited >> >> power to customize a DSL. >> >> >> But he replied: >> >> * there is a lower cost for me to quickly get what I need: expressive >> >> builder expressions in a langage (groovy) that I can grasp very >> >> quickly >> >> >> And I also thought for myself: >> >> * power is good, but it would not be easy for my friend to *quickly* >> >> get the same as groovy builders provide, *because* they provide a >> >> "framework" which guides him. >> >> >> So, again, did anybody write something *functionally* similar to >> >> groovy builders already ? >> >> >> I would see such project a good way to have more java users become >> >> familiar to clojure "at a low cost", hopefully making them the switch >> >> less costly at firt. >> >> > People choose languages for a project (myself included) for some >> > of the oddest reasons sometimes... >> >> > But it's interesting you mention builders -- I hadn't heard the >> > term until reading a section Fogus wrote for our book. I guess >> > I can't link to it here quite yet, but in essence he walks you >> > through how to use normal Clojure literal map syntax in place of >> > fluent builders. This of course requires essentially no >> > framework code at all, either to support builders in general or >> > for any specific application's builder needs. >> >> > So perhaps what your friend needs is just an example or >> > description of how to proceed in Clojure, not actually any >> > library code at all. >> >> That's what I also thought first. And then I came to carefully look at >> what Groovy builders are, and I think there may be more than just >> "showing people how to do builders in clojure" (although for the >> common cases having an article explaining that would certainly be >> invaluable for newcomers). >> >> Unless I'm thinking wrong, with plain function calls in clojure, you >> presuppose that the construction of the final product is done as >> persistent datastructures are built: from bottom to top. >> With groovy builder, though, there is no such "hard-wired" >> presupposition: the build functions are passed closures, and they call >> the closure whenever they want, thus allowing the children to be >> constructed before or after the parent (a lot of real-world builders >> for java frameworks which use mutable datastructures require the >> clients to be passed a reference to the parent). >> >> Thus the "generic" builder framework offered by Groovy builders resembles >> this: >> >> (make-foo-node nil {:prop1 val1 :prop2 val2 ... } (fn >> make-foo-node-children [parent-instance] (make-bar-node >> parent-instance {:prop3 val3 ...} (fn make-bar-node-children ...)) ; >> I'm certainly missing parameters here >> >> and not this: >> (make-node-type-foo {:prop1 val1 :prop2 val2 ...} [ >> (make-node-type-bar ...) (make-node-type-bar ...) ]) >> >> So the groovy version hard-wires some convention over the signatures >> of the "makers" methods, how things written in the DSL look like (good >> when jumping from one project to another, "recognizable pattern" - at >> least for common things). >> I guess those things are important to make the barrier entry "low >> enough" for people which do not feel "at home" with lisps yet. >> >> OH YES, I also thing we could achieve an even more "type safe" version >> than groovy builders, since I guess a lot of stuff is done at runtime >> by groovy builders (especially reflection for setting java bean >> properties from literal maps, finding the right method to call by >> examining the method name in a generic unknown method handler) ... so >> by leveraging the power of clojure macros, one could potentially mix >> the beauty of synctactically elegant DSLs with compiler checks by >> doing the reflection stuff at macro-compile time (and then get >> feedback on "no such field exception" at compile time !! ! ! ) >> >> If nobody did too much investigation into "encapsulating" some common >> pattern into a little lib of its own, maybe I'll investigate a little >> bit in this area, to see by practice if it's interesting or not. > > -- > 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 -- 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
