After some experience with excessively meta-programmed Ruby apps, I generally try to design an API that is as clean (or almost) as what I'm tempted to generate and avoid the metaprogramming. For example (api/get-user-by-id "123") is only slightly nicer than (api/get-by-id :user "123"), so if the former requires code that some of the team will be afraid to touch, or requires an extra build step, I prefer the latter.
Maybe if you spell out some of the boiler-plate you want to eliminate we'll have a better idea of what you're trying to achieve. On Mon, Nov 18, 2013 at 8:51 PM, Jeremy Heiler <jeremyhei...@gmail.com>wrote: > On Mon, Nov 18, 2013 at 7:48 PM, Jeremy Heiler <jeremyhei...@gmail.com>wrote: > >> I am interested in what you think about generating functions at compile >> time (with a macro) from data. The specific use case I am thinking about >> pertains to libraries for large web services with a lot of endpoints. A >> cost-benefit analysis could probably be done for what size is appropriate, >> but lets just assume the number of endpoints is large enough for you to >> start thinking about this. >> >> Potential advantages include: >> >> - Less boilerplate. It would be less annoying to maintain data that >> represents each endpoint and generate the boilerplate than it is to >> maintain a lot of repetitive code. >> >> - Shareable. The work done to maintain the endpoint data could be used by >> multiple libraries for multiple languages. In fact, it could be maintained >> by the web service itself. >> >> Potential disadvantages include: >> >> - Limited discoverability. If the code is generated at compile time, >> there is no direct source for it, which may hinder the ability to view or >> generate documentation with your favorite tool(s). >> >> - Complicated edge cases. Endpoints that require extra code are usually >> edge cases, but not always. Regardless, breaking from the template may >> complicate the code further. (I don't think this is a difficult problem to >> solve, though.) >> >> One way to alleviate the "limited discoverability" problem is to generate >> source code at build time. This is what you would do in langauges like >> Java, and that has always left me frustrated, so I am not inclined to think >> it's a good idea. However, feel free to make the case! >> >> A language like Clojure makes doing this relatively easy, but is it >> simple? >> > > Another consequence of this that I forgot to mention in the mail above is > that there will either need to be way for the library to self-execute the > macro or require the user to initialize the library. The latter might not > be too bad considering global (immutable) configuration such as > authentication credentials and URLs are necessary. > > -- > -- > 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. > -- http://elhumidor.blogspot.com/ -- -- 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.
