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
