On Mon, Jan 12, 2009 at 11:38 PM, Paul Davis <paul.joseph.da...@gmail.com> wrote: > On Tue, Jan 13, 2009 at 2:27 AM, Chris Anderson <jch...@gmail.com> wrote: >> On Mon, Jan 12, 2009 at 11:08 PM, Ulises <ulises.cerv...@gmail.com> wrote: >>> +1 on render >>> >>> The other thing I think we must think about, since we're discussing >>> naming here, is that I'd hate to have two different names one for >>> show_docs and one for show_views. From a user's point of view, I >>> wouldn't care really whether the info I'm looking at came from >>> _show_docs or _show_view. >>> >>> _render is good IMO. >>> >>> /db/_view/_render/as_foo >>> /db/docid/_render/as_foo <- (I must confess I haven't looked at the >>> whole _show feature in details so some things I say may be way off) >>> >> >> When we were discussing names on IRC, _render came up, but we liked >> _show better. I think mostly because it was shorter, but I think it >> also gets across the side-effect free nature of the functions pretty >> well (not that _render doesn't.) _render is basically fine... I do >> think I like _show and _list as a pair better, but I'm not set on them >> by any means. I think we'll need them to be different names, the >> question is whether they should be related, like _render_one and >> _render_many or if its fine to be a little more relaxed, like _show >> and _list. >> >> Something worth clearing up about my example. It would be bad form to >> have a function called "by-html" and I probably shouldn't have used it >> as an example. The better way to go would be a function called >> "blog-posts-by-date" which can satisfy client requests for >> "application/atom+xml", "application/rss+xml", and "text/html". This >> switching on Accept header is already implemented for doc show >> functions and demonstrated in the test suite. >> >> As far as paths go, there are various good reasons we should stick to >> the /db/_the_feature_name/... and not /db/.../_the_feature_name >> > > But give us a couple words on why _the_doc_feature needs to be > different than _the_view_feature >
Mostly because you use them for different things. If you're a client library, it'd be nice to know that the view query options apply to path A, and the doc query options apply to path B. Also I think having different names will make it easier to work with them, talk about them, etc... they are different functions, after all. Even if we could squeeze both into the same name space, it doesn't feel very relaxing. -- Chris Anderson http://jchris.mfdz.com
