I’m in favour of doing something like this.
How about adding them to the function in question?
So
function(doc) {
emit(doc.key)
}
would become
function(doc) {
this.emit(doc.key)
}
+1. no need to mess with the function signature.
+2. no clunky here’s-a-bunch-functions object that isn’t already there.
+3. most upgrades are string replace away.
-1. overloading this could be seen as clunky in itself.
-2. still doesn’t solve that `function() {}` is not valid JavaScript and
doesn’t work in newer SpiderMonkeys or other engines. But that might be out of
scope.
Best
Jan
--
> On 02 Dec 2015, at 14:06, Alexander Shorin <[email protected]> wrote:
>
> 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 <[email protected]> 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 <[email protected]> wrote:
>>>
>>> Hi Garren,
>>>
>>> On Wed, Dec 2, 2015 at 3:35 PM, Garren Smith <[email protected]> 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 (:
>>>
>>> --
>>> ,,,^..^,,,
>>
