While I like require(...) way to handle this issue, I will allow myself to disagree with the emit argument in function signature. Because if we upgrade SM to get generators feature then we can throw away emit at all. Map functions are perfect generators and Python query server experience showed that this is great idea. SM / JS support upgrade is unavoidable, so let's look a little bit far in the future to now fix same things twice (;
-- ,,,^..^,,, On Wed, Dec 2, 2015 at 4:01 PM, Garren Smith <gar...@apache.org> wrote: > Ok you make good points and I wasn’t aware of all these functions > http://docs.couchdb.org/en/1.6.1/query-server/javascript.html > <http://docs.couchdb.org/en/1.6.1/query-server/javascript.html> > I’m going to do one more bike shed and then I will leave it up to you and > other people who actually want to implement this. > For the case of map reduce, I would go with a function call like I said before > > function (doc, emit) { > > } > > Then for all our other helpers I would make them available through a require. > This in my mind makes it similar to node.js or to a browser if you use > browserify, web pack, requirejs etc > So a full example would be > > function (doc, emit) { > var isArray = require(‘helpers’).isArray; > var allHelpers = require(‘helpers’); > > > } > > That is my 2 cents worth. > > Cheers > Garren > >> On 02 Dec 2015, at 2:42 PM, Alexander Shorin <kxe...@gmail.com> wrote: >> >> Hi Garren, >> >> On Wed, Dec 2, 2015 at 3:35 PM, Garren Smith <gar...@apache.org> wrote: >>> >>> This is an interesting idea. I think passing the emit function in is a good >>> idea and might make somethings easier in PouchDB. I would rather a map >>> function looked something like this >>> >>> function (doc, emit) { >>> >>> } >> >> That's nice, but won't work: map function has access to a lot of other >> global functions we provide, so you'll end with signature of 7 >> arguments. I don't think there is any reason to fix this problem by a >> half. Just fix all globals or no one. >> >>> I don’t like the idea of passing a userCtx object. That feels overly bulky. >>> Things like JSON/require are global variables in Node.js or the browser so >>> my feeling is to follow their lead on those. >> >> ctx referenced not to userCtx, but a generic context object that hold >> all the global function and objects we provide now. These are listed >> in reference on documentation. May be we can find a better name to not >> cause confusion. funcs? env? Suggestions welcome (: >> >> -- >> ,,,^..^,,, >
