> this.emit(doc.key)
Normally this.propName points to the ddoc property, if any. So better
this._emit since properties with _ are prohibited for docs.
ermouth
2015-12-12 16:03 GMT+03:00 Jan Lehnardt <j...@apache.org>:
> 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 <kxe...@gmail.com> 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 <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 (:
> >>>
> >>> --
> >>> ,,,^..^,,,
> >>
>
>
