Re: [PROPOSAL] Deprecate global functions in query server
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 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 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
>>
>> 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 wrote:
>>>
>>> Hi Garren,
>>>
>>> On Wed, Dec 2, 2015 at 3:35 PM, Garren Smith 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 (:
>>>
>>> --
>>> ,,,^..^,,,
>>
Re: [PROPOSAL] Deprecate global functions in query server
> 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 :
> 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 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 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 wrote:
> >>>
> >>> Hi Garren,
> >>>
> >>> On Wed, Dec 2, 2015 at 3:35 PM, Garren Smith
> 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 (:
> >>>
> >>> --
> >>> ,,,^..^,,,
> >>
>
>
Re: [PROPOSAL] Deprecate global functions in query server
So I'm a lurker here and most of you don't know me, so feel free to ignore
my opinion here :-). I've only been getting into CouchDB heavily lately,
but have been doing JavaScript for quite a few years.
My first thought is that whatever change is going to me made here that be
done such that it leads to forward compatibility with JavaScript moving
forward (i.e. newer *Monkeys or other engines). My feeling is that,
eventually, CouchDB is going to have "bite the bullet" and move towards
compatibility with current JS standards (if for nothing else, to leverage
the huge leaps in performance made in engines in the past few years).
Therefore, my opinion here, for whatever its worth, is that these changes
(moving off of the global and towards modern JS syntax) be made all at
once. Maybe leverage the "use strict"; or some other directive that was
introduced in ECMAScript 5 to distinguish between a newer "no global, ES5+
compatible syntax" and the older syntax.
My 2 cents.
Cheers,
- Bill
On Sat, Dec 12, 2015 at 10:12 AM, ermouth wrote:
> > 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 :
>
> > 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 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
> 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
> wrote:
> > >>>
> > >>> Hi Garren,
> > >>>
> > >>> On Wed, Dec 2, 2015 at 3:35 PM, Garren Smith
> > 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 (:
> > >>>
> > >>> --
> > >>> ,,,^..^,,,
> > >>
> >
> >
>
