Perhaps I have an incomplete grasp of the problem domain, but wouldn't a map stored in a ref let you do this?
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
