I'd suggest avoiding macros until you absolutely know that you need them. Usually they aren't necessary.
Problem with this is that you don't really know when you need them unless you know what they do. On Thu, Aug 8, 2013 at 9:58 PM, Jace Bennett <jace.benn...@gmail.com> wrote: > 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. > -- -- 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.
