Thanks, Mike. I guess my simple example is too simple. Out of the hypothetical, have you used techniques like this?
I have this nagging feeling that there is a more direct and idiomatic way to glean this sort of information from my code. I mean, that's why we use AST's, right? So we can process them? I shouldn't need a data structure like the endpoint map in the first place. I just don't know how to capitalize on this rather abstract and vague notion. How do folks usually go about it when they have a desire to query the running system about its shape and structure? On Thu, Aug 8, 2013 at 2:36 AM, Mikera <mike.r.anderson...@gmail.com> wrote: > I'd suggest avoiding macros until you absolutely know that you need them. > Usually they aren't necessary. > > Prefer writing pure functions (without side effects) - these are easier to > reason about, easier to test, simpler to write correctly and easier to plug > together / compose via higher order functions. > > For example, in your endpoint example I would probably just use three > functions: > - a pure "add endpoint metadata to an endpoint map" function > - an impure "update endpoints" function that updates endpoints using an > endpoint map > - a function that calls both of the above to declare and launch a new > endpoint > > There might be a few other helper functions as well but hopefully you get > the idea. > > > On Thursday, 8 August 2013 03:19:15 UTC+1, Jace Bennett wrote: >> >> Thanks to the community for a wondrous programming environment. I >> discovered SICP last year, and fell in love with the idea of lisp. But I've >> come to a point where I think I need practice on moderately sized projects >> before more reading will help. >> >> When starting on almost any moderately scoped effort, I quickly run into >> a class of problems which I think may be a fit for macros, but I want to >> understand what is the idiomatic way to approach them in clojure. >> >> Most of my professional experience is in .NET, and that is probably >> coloring my thought patterns a bit. In that context, I often use reflection >> scans and type metadata to configure infrastructural bits and dry things >> up. Instead of having to explicitly register components in the more dynamic >> areas of my app, I use conventions to select components to register from >> the metadata I have about my code. >> >> I can imagine using macros in clojure to accumulate metadata about my >> declarations so that I can query them at runtime. For example, maybe a >> "defendpoint" macro that sets up a handler AND adds it to the routing table >> (or more directly an "endpoint map" which I then use to make routing >> decisions among other things). >> >> Admittedly, something about the sound of the phrase "it's just data" >> tells me I'm sniffin up the wrong tree here. But I don't know how to turn >> that nagging feeling into working code. >> >> Is this a reasonable use of the macro? What about doing the registration >> at macro-expansion time vs emitting runtime code to do it? How should one >> approach the problems space otherwise? >> >> Thanks for your time. >> > -- > -- > 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 unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.