[jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
[
https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13201180#comment-13201180
]
James Howe commented on COUCHDB-1397:
-
@Marcello - for unit testing you can do what CommonsJS does (and Jason points
to) in order to define the globals.
var map_runner = function (emit, log, sum) { + map_value + }
Function expressions, evals in SpiderMonkey
---
Key: COUCHDB-1397
URL: https://issues.apache.org/jira/browse/COUCHDB-1397
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 1.2.1
Environment: All
Reporter: Jason Smith
New SpiderMonkey releases do not eval() a sole anonymous function expression.
That is not a valid JavaScript statement, and so it is not a valid JavaScript
script.
COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for
1.2. (Sorry to spam COUCHDB-1302. I saw Unassigned and read Unresolved.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
[ https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13201198#comment-13201198 ] Marcello Nuccio commented on COUCHDB-1397: -- @James, that's what I'm doing. I find that tests written this way are more complex with respect to tests I write for other things. But, I'm clearly missing something obvious here, since I'm alone on this. Function expressions, evals in SpiderMonkey --- Key: COUCHDB-1397 URL: https://issues.apache.org/jira/browse/COUCHDB-1397 Project: CouchDB Issue Type: Bug Components: JavaScript View Server Affects Versions: 1.2.1 Environment: All Reporter: Jason Smith New SpiderMonkey releases do not eval() a sole anonymous function expression. That is not a valid JavaScript statement, and so it is not a valid JavaScript script. COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for 1.2. (Sorry to spam COUCHDB-1302. I saw Unassigned and read Unresolved.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
[ https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13201204#comment-13201204 ] Jason Smith commented on COUCHDB-1397: -- @All: I am fascinated and excited about the discussion of unit testing Couch apps more easily. Would you mind moving this discussion to the dev@ and user@ list? (These JIRA tickets are sent there, so you can simply hit reply from your mailer.) @Dave, thanks again for your thoughts. In this thread, your arguments seem to have resonated more strongly than mine. I hope you'll chew over Max's point that, if our goal is more well-formed, valid Javascript as a means of exporting functionality to a larger framework, then CommonJS should be a strong favorite. Function expressions, evals in SpiderMonkey --- Key: COUCHDB-1397 URL: https://issues.apache.org/jira/browse/COUCHDB-1397 Project: CouchDB Issue Type: Bug Components: JavaScript View Server Affects Versions: 1.2.1 Environment: All Reporter: Jason Smith New SpiderMonkey releases do not eval() a sole anonymous function expression. That is not a valid JavaScript statement, and so it is not a valid JavaScript script. COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for 1.2. (Sorry to spam COUCHDB-1302. I saw Unassigned and read Unresolved.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
[
https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13200798#comment-13200798
]
Marcello Nuccio commented on COUCHDB-1397:
--
@Alexander,
this isn't as off-topic as it seems at first, because software design is
heavily influenced by ease of testability.
I've not proposed to inject every single function. I've proposed to inject the
context. For a list function it may be:
function aList(head, req, ctx) {
var row;
function renderRow(row) { //... }
while((row = ctx.getRow())) {
send(renderRow(row));
}
}
This greatly simplifies unit testing. And it does not imply that you mock
every internal query server global function. You can even do without mocking,
but the point is that you are in control of it, so you can properly test
whatever needs testing.
Testing with the real query server, is done in end-to-end or integration
testing. This is needed, but it does not eliminate the need for unit testing.
Function expressions, evals in SpiderMonkey
---
Key: COUCHDB-1397
URL: https://issues.apache.org/jira/browse/COUCHDB-1397
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 1.2.1
Environment: All
Reporter: Jason Smith
New SpiderMonkey releases do not eval() a sole anonymous function expression.
That is not a valid JavaScript statement, and so it is not a valid JavaScript
script.
COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for
1.2. (Sorry to spam COUCHDB-1302. I saw Unassigned and read Unresolved.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
Hi, Marcello and Alexander. Perhaps we can move this to the mailing
list and off the JIRA ticket?
On Sun, Feb 5, 2012 at 11:21 PM, Marcello Nuccio (Commented) (JIRA)
j...@apache.org wrote:
[
https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13200798#comment-13200798
]
Marcello Nuccio commented on COUCHDB-1397:
--
@Alexander,
this isn't as off-topic as it seems at first, because software design is
heavily influenced by ease of testability.
Firstly, I'm unsure if you noticed but I made a typo which gave my
statement the opposite meaning.
I agree that emit(), log(), etc. should NOT be global.
However, I disagree that they should be passed to map(), simply
because it burdens the programmer. Plus, if we add new functions in
the future, it would change the call signature of map functions. On
the other hand, we get the same benefit by passing the functions but
using a closure to put them in scope of map(), reduce(), etc.
The map function might be built like so (the example is imperfect but
I'm aiming for clarity for now):
Given: ddoc.views.people.map = module.exports = function(doc) {
emit(doc.name, 1) }
var make_map = Function(require, module, exports, emit, log,
ddoc.views.people.map)
var map = make_map(require, module, exports, emit, log)
map({name:Bob}) // Runs emit(Bob, 1)
## Unit testing
It's imperfect for unit testing; however I think a hypothetical NPM
package would be fine. It could convert the ddoc functions to
JavaScript functions in a similar fashion. (Below is the first API
that popped into my head, no doubt we could make better.)
var assert = require('assert')
, couch = require('mock-couchdb')
var ddoc = couch.load_ddoc({views: {people: {map: function(doc) {
emit(doc.name, 1) )
var emitted
ddoc.on('emit', function(key, val) { emitted = key })
ddoc.views.people.map({name:Bob})
assert.equal(emitted, Bob)
--
Iris Couch
Re: [jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
On Mon, Feb 6, 2012 at 8:04 AM, Jason Smith j...@iriscouch.com wrote:
## Unit testing
It's imperfect for unit testing; however I think a hypothetical NPM
package would be fine. It could convert the ddoc functions to
JavaScript functions in a similar fashion. (Below is the first API
that popped into my head, no doubt we could make better.)
var assert = require('assert')
, couch = require('mock-couchdb')
var ddoc = couch.load_ddoc({views: {people: {map: function(doc) {
emit(doc.name, 1) )
var emitted
ddoc.on('emit', function(key, val) { emitted = key })
ddoc.views.people.map({name:Bob})
assert.equal(emitted, Bob)
--
Iris Couch
Failing all of that, my personal second choice would be to put all of
those functions in their own CommonJS module.
// map
module.exports = function(doc) {
var couch = require('couch')
couch.emit(doc.name, 1)
}
--
Iris Couch
Re: [jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
Hi, Jason!
I'd like to share your disagreement about global functions (emit, log,
send etc.) if only I haven't rewritten query server line by line.
Actually, they are start to be global at function source code
compilation[1][2], so nobody stops you to change their context. But
you may notice, that view functions shares some invalid functions for
their context. e.g.
function(doc){
emit(doc.foo, 1);
while(row=getRow()){
// ooops...(:
}
}
So you just wanted to have some control on function compilation
context? I suppose Couch[3] object could help you to define custom
context, overload default emit, log and other functions. May be using
Javascript query server internals a little unhandy, but some wrappers
could make it sweet(:
Hiding current global function to some object or module means
breaking all design function. Idea with requiring them (I mean your
`var couch=require(couch);`) looks nice from code design style, but
as lazy developer this looks like overhead that I should write because
without it my functions couldn't work at all! Not so relaxed as it
currently does.
About testing couchapps.
IMHO, there is no problem(: Function context could be easily
overloaded, but I dont think that unittests are good idea for them.
For testing Python couchapps I'd prefer black box testing[4] instead
of unit one because of some simple reasons.
Main profit of black box testing in this case that it works as is, I
dont have to care about mocking global function, emulating CommonJS,
mime type guessing routines etc. they are just have done well and
works well. If I need test against some CouchDB version, I just
specify target version and I'm aware about some specific behavior of
them - unittests couldn't get me such information.
For example, I could easily mock require function and make CommonJS
modules works for view functions, but these functions wouldn't
actually work in CouchDB before 1.1 version - this feature just was
not implement(:
Also, it's a simple task to test views, but much more pain you will
get by testing show and list functions[5], especially for second one
because they working in bi-direction way: reading input stream while
output is not finished, collecting chunks stack and flushing them back
for each getRow round...hellish function for well unit testing(:
So, resuming wall of text above:
0. Design function context could be customized;
1. Wrapping current pseudo global functions to CommonJS module or some
context object breaking a lot of code and makes it useless without
additional work;
2. Query server internals could help you in testing your couchapps;
3. Couchapps unittests are too synthetic and couldn't revive all
possible problems. Should you do same work twice?
[1] https://github.com/apache/couchdb/blob/master/share/server/util.js#L64
// compilation
[2] https://github.com/apache/couchdb/blob/master/share/server/loop.js#L16
// namespace definition
[3] https://github.com/apache/couchdb/blob/master/share/server/util.js#L59
// Couch object
[4]
https://code.google.com/r/kxepal-couchdb-python-featured/source/browse/couchdb/tests/server/qs.py?name=viewserver#241
// very simple and synthetic, but I'm awaiting for Dirkjan review of
current state before adding more features to simplify testing(:
[5]
https://code.google.com/r/kxepal-couchdb-python-featured/source/browse/couchdb/tests/server/render.py?name=viewserver#235
--
,,,^..^,,,
On Mon, Feb 6, 2012 at 5:04 AM, Jason Smith j...@iriscouch.com wrote:
Hi, Marcello and Alexander. Perhaps we can move this to the mailing
list and off the JIRA ticket?
On Sun, Feb 5, 2012 at 11:21 PM, Marcello Nuccio (Commented) (JIRA)
j...@apache.org wrote:
[
https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13200798#comment-13200798
]
Marcello Nuccio commented on COUCHDB-1397:
--
@Alexander,
this isn't as off-topic as it seems at first, because software design is
heavily influenced by ease of testability.
Firstly, I'm unsure if you noticed but I made a typo which gave my
statement the opposite meaning.
I agree that emit(), log(), etc. should NOT be global.
However, I disagree that they should be passed to map(), simply
because it burdens the programmer. Plus, if we add new functions in
the future, it would change the call signature of map functions. On
the other hand, we get the same benefit by passing the functions but
using a closure to put them in scope of map(), reduce(), etc.
The map function might be built like so (the example is imperfect but
I'm aiming for clarity for now):
Given: ddoc.views.people.map = module.exports = function(doc) {
emit(doc.name, 1) }
var make_map = Function(require, module, exports, emit, log,
ddoc.views.people.map)
var map = make_map(require, module, exports, emit, log)
map({name:Bob}) // Runs emit(Bob, 1)
## Unit testing
It's imperfect for unit
[jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
[
https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13200384#comment-13200384
]
Marcello Nuccio commented on COUCHDB-1397:
--
@Jason,
I've found that, using valid Javascript in map/reduce, eases development for
me, because I can use standard tools (uglifyjs, jshint, ...) without extra work.
Moreover, I would also remove all global functions and inject them:
function sampleMap(doc, view) {
view.emit(doc._id, null);
}
because this makes unit testing much more easier than now.
Ease of development and ease of testing it's much more relaxing for me, than
the possibility to use anonymous functions.
Function expressions, evals in SpiderMonkey
---
Key: COUCHDB-1397
URL: https://issues.apache.org/jira/browse/COUCHDB-1397
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 1.2.1
Environment: All
Reporter: Jason Smith
New SpiderMonkey releases do not eval() a sole anonymous function expression.
That is not a valid JavaScript statement, and so it is not a valid JavaScript
script.
COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for
1.2. (Sorry to spam COUCHDB-1302. I saw Unassigned and read Unresolved.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
[
https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13200387#comment-13200387
]
Jason Smith commented on COUCHDB-1397:
--
@Marcello, yes I am okay with the idea of JavaScript programs (I've realized
the word invalid is not helpful in this discussion).
However once again, CommonJS is the clear, obvious goal. It clarifies and
unifies CouchDB, and CouchApps would immediately become Node.js apps (at least,
you could require() their parts for unit testing which I have started to do as
well.)
I agree that emit(), log(), etc. should be global; but I disagree that they can
be injected. There is a third way, the way CommonJS works. The code is
implicitly wrapped in a larger function where `emit`, `log`, etc. had been
passed as parameters.
In CommonJS, your code is inside a function--not even conceptually, really. See
share/server/util.js, around line 90.
var s = function (module, exports, require) { + newModule.current + };
This is the sort of source code transforms I hope Paul would agree is fine. If
newModule.current was wrong before (suppose it defined an anonymous function),
then it is still wrong. And this pattern is well-known and well-exercised in
several JavaScript environments. Perhaps one day there will be:
var map_runner = function (emit, log, sum) { + map_value + }
Function expressions, evals in SpiderMonkey
---
Key: COUCHDB-1397
URL: https://issues.apache.org/jira/browse/COUCHDB-1397
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 1.2.1
Environment: All
Reporter: Jason Smith
New SpiderMonkey releases do not eval() a sole anonymous function expression.
That is not a valid JavaScript statement, and so it is not a valid JavaScript
script.
COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for
1.2. (Sorry to spam COUCHDB-1302. I saw Unassigned and read Unresolved.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
[
https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13200471#comment-13200471
]
Marcello Nuccio commented on COUCHDB-1397:
--
@Jason,
CommonJS is fine, but it doesn't help for unit testing. CommonJS is a linker
(runs on load time), dependency injection is done at run-time. One assembles
code, the other object graph. Not the same thing.
To ease unit testing, you need dependency injection. You can't easily test:
function (doc) {
var util = require('views/lib/util');
if (util.isSomething(doc)) {
emit(doc._id, 1);
}
}
It's doable (I'm doing it), but not easy. Testing the following is trivial:
function (doc, view, require) {
var util = require('views/lib/util');
if (util.isSomething(doc)) {
view.emit(doc._id, 1);
}
}
Globals, make the code harder to:
- read (where do these values come from?);
- test (how do I mock globals at run-time?);
- write (you need to tell to your code-checker what globals you use.)
Function expressions, evals in SpiderMonkey
---
Key: COUCHDB-1397
URL: https://issues.apache.org/jira/browse/COUCHDB-1397
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 1.2.1
Environment: All
Reporter: Jason Smith
New SpiderMonkey releases do not eval() a sole anonymous function expression.
That is not a valid JavaScript statement, and so it is not a valid JavaScript
script.
COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for
1.2. (Sorry to spam COUCHDB-1302. I saw Unassigned and read Unresolved.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
[
https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13200525#comment-13200525
]
Alexander Shorin commented on COUCHDB-1397:
---
[offtopic]
Sorry for offtopic, but
@Marcello,
Why not to use black box testing instead of trying to mock every internal query
server global function? Using QS directly as black box you will have warranty
that your functions are tested well, because box is real, but you don't have to
know how it works. In your way you testing for your own, may miss some details
and output result could be different. This is not only about views that are not
so complex as show or list functions. By the way, applying your idea to other
functions I'll something weird for list function:
function(head, req, provides, registerType, getRow, send, start,
whatEverWillBeAddedInFuture){
...
}
Looks not much relaxing(: Certainly, Javascript allows to skip some function
arguments definition, but it still requires(?) them in right order.
And what about other query servers in this case? Currently, they are doing same
work as Javascript one or just trying to do, but not all of them could skip
arguments definition, has arguments vectors etc. This could create additional
problems with migration from one QS to another.
[/offtopic]
About subject, I couldn't say anything important about function(...){} vs
function name(...){} vs ... because I don't use Javascript query server, but in
Python I have to write real functions with their names - it works as nice
marker to find their crush in debug logs if it happens, so for me this is just
nice feature(:
P.S. Just a moment, what will happens with CoffeeScript in case of proposed
changes?
Function expressions, evals in SpiderMonkey
---
Key: COUCHDB-1397
URL: https://issues.apache.org/jira/browse/COUCHDB-1397
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 1.2.1
Environment: All
Reporter: Jason Smith
New SpiderMonkey releases do not eval() a sole anonymous function expression.
That is not a valid JavaScript statement, and so it is not a valid JavaScript
script.
COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for
1.2. (Sorry to spam COUCHDB-1302. I saw Unassigned and read Unresolved.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
[ https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13199616#comment-13199616 ] James Howe commented on COUCHDB-1397: - For Paul's example alternatives, is it not a trivial operation to convert the old format to these internally before eval? Then users can do what they've always done (and don't have to worry about new ways to ty[po) and the SM-related problem is solved. Function expressions, evals in SpiderMonkey --- Key: COUCHDB-1397 URL: https://issues.apache.org/jira/browse/COUCHDB-1397 Project: CouchDB Issue Type: Bug Components: JavaScript View Server Affects Versions: 1.2.1 Environment: All Reporter: Jason Smith New SpiderMonkey releases do not eval() a sole anonymous function expression. That is not a valid JavaScript statement, and so it is not a valid JavaScript script. COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for 1.2. (Sorry to spam COUCHDB-1302. I saw Unassigned and read Unresolved.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
[
https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13199668#comment-13199668
]
Paul Joseph Davis commented on COUCHDB-1397:
@Jason
Of course I'd look at a patch if you have one. Though as I've mentioned before,
anything that relies on parsing JavaScript or other source-to-source transforms
is going to be heavily discouraged. Also, while I understand that this will
change things from the old method, I'm not overly swayed by the relaxing
arguments here. Fact of the matter is that this is invalid JavaScript, so
regardless of what we do, it should at least be valid JavaScript. (And jslint
and other command line tools would finally start working as well).
@Jason, @Max, @James
I tried doing some hacky shortcuts to account for this. Specifically, ( +
map_source + ) because the error is literally anonymous function at top
level scope or some such and the parens make it kosher. But this ends up
breaking all of the code that looks like var f = 1; function(doc)
{emit(doc._id, f);}; which is a noticeable amount of JavaScript.
@Jason, @Max, @James
I did just think of an alternative solution which would be to make the new
version use scripts instead of functions. The resulting syntax would be
something like:
var doc = next_doc(); emit(doc._id, null)
Which would then just be executed once for every doc. Though going this route,
we'd need some sort of context for the functions so people could precompile
their CommonJS libs and the like.
Function expressions, evals in SpiderMonkey
---
Key: COUCHDB-1397
URL: https://issues.apache.org/jira/browse/COUCHDB-1397
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 1.2.1
Environment: All
Reporter: Jason Smith
New SpiderMonkey releases do not eval() a sole anonymous function expression.
That is not a valid JavaScript statement, and so it is not a valid JavaScript
script.
COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for
1.2. (Sorry to spam COUCHDB-1302. I saw Unassigned and read Unresolved.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
[
https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13199697#comment-13199697
]
Jason Smith commented on COUCHDB-1397:
--
@Paul
We really need to define invalid JavaScript and distinguish it from invalid
CouchDB programming which is why I wrote Fact #6.
For example, Benoit suggested that we could provide only the function *bodies*.
They are implicitly wrapped in a function(doc) { ... }. That's neat! In a world
where CouchDB had always worked that way, we would all call emit(doc._id,
null) *valid CouchDB* but we know it is invalid JavaScript (doc is unbound).
I take you to mean that valid CouchDB implies valid JavaScript.
But valid CouchDB is more relaxing with anonymous functions (invalid
JavaScript). Business as usual is beautiful.
How could it be implemented on all SM versions? What if we catch the eval()? If
the error is anonymous function at a top level scope then we try again with
(+code+). Yes, it is a tiny source transformation, and that is bad; however
it is a common idiom in Javascript when building code from data.
(If you ask me, it is the helper function people who should see their code
broken; not we who have followed the customs and conventions all along. Thus I
prefer your original patch the most: wrap it in parens.)
Function expressions, evals in SpiderMonkey
---
Key: COUCHDB-1397
URL: https://issues.apache.org/jira/browse/COUCHDB-1397
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 1.2.1
Environment: All
Reporter: Jason Smith
New SpiderMonkey releases do not eval() a sole anonymous function expression.
That is not a valid JavaScript statement, and so it is not a valid JavaScript
script.
COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for
1.2. (Sorry to spam COUCHDB-1302. I saw Unassigned and read Unresolved.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
[ https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13199714#comment-13199714 ] Paul Joseph Davis commented on COUCHDB-1397: @Jason I reject the premise that there's a distinction to be made between valid JavaScript and valid CouchDB programming. At this point I would say that if its not possible to have whatever we decide pass jslint in a copy/paste manner, then its not valid anything. Also, the function body thing is the same thing I suggested as an aside except that the wrapping it in a function part is useless and will lead to more issues than it solves. Also, it has the same issues that if you did do it, the included code would be executed everytime (ie, if you pulled in a large helper it would redefine everything again (also note, this is not the same as compilation)). Function expressions, evals in SpiderMonkey --- Key: COUCHDB-1397 URL: https://issues.apache.org/jira/browse/COUCHDB-1397 Project: CouchDB Issue Type: Bug Components: JavaScript View Server Affects Versions: 1.2.1 Environment: All Reporter: Jason Smith New SpiderMonkey releases do not eval() a sole anonymous function expression. That is not a valid JavaScript statement, and so it is not a valid JavaScript script. COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for 1.2. (Sorry to spam COUCHDB-1302. I saw Unassigned and read Unresolved.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
[
https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13199747#comment-13199747
]
James Howe commented on COUCHDB-1397:
-
There's nothing Invalid about this javascript: {map: function(doc) {}},
it's only the way it's used (i.e. blindly eval'd) that is invalid. A
source-to-source translation cold be s/\bfunction\(/function map(/.
IMO, it is the people writing {map: var d=1; function(doc) { emit(doc._id,
d);} that should find their code not working, as they are using undocumented
features.
If changes are to be made, I much prefer Benoit's suggestion - having doc be
implicit in the context and the value of map keys being function bodies.
emit already works like this, so makes no difference to JSLintability.
Function expressions, evals in SpiderMonkey
---
Key: COUCHDB-1397
URL: https://issues.apache.org/jira/browse/COUCHDB-1397
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 1.2.1
Environment: All
Reporter: Jason Smith
New SpiderMonkey releases do not eval() a sole anonymous function expression.
That is not a valid JavaScript statement, and so it is not a valid JavaScript
script.
COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for
1.2. (Sorry to spam COUCHDB-1302. I saw Unassigned and read Unresolved.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
[
https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13199766#comment-13199766
]
Paul Joseph Davis commented on COUCHDB-1397:
Erm, I'd like to point out that the string function(doc) {} actually *is*
invalid JavaScript. Anonymous functions at global scope are specifically not
ok. Although anonymous functions in a statement context *are* ok. Its a subtle
distinction but its quite important.
Also, just today I came across a scenario of compiling a regular expression
outside the function scope as a valid use of the helper pattern.
Function expressions, evals in SpiderMonkey
---
Key: COUCHDB-1397
URL: https://issues.apache.org/jira/browse/COUCHDB-1397
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 1.2.1
Environment: All
Reporter: Jason Smith
New SpiderMonkey releases do not eval() a sole anonymous function expression.
That is not a valid JavaScript statement, and so it is not a valid JavaScript
script.
COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for
1.2. (Sorry to spam COUCHDB-1302. I saw Unassigned and read Unresolved.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
[ https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13199794#comment-13199794 ] Jason Smith commented on COUCHDB-1397: -- And since when has the contents of map become a global scope? Who made that decision? Was it you? Really, if eval() is the only arrow in your quiver then it's no wonder you see the problem this way. And how have you decided so-called source-to-source translations are out of the question? They are the backbone of JavasScript encapsulation, undergirding CommonJS (CouchDB and Node), RequireJS, Ender.js, and no doubt more. It's just a couple of parens on either side. Look into your heart. You know it's the right call. Function expressions, evals in SpiderMonkey --- Key: COUCHDB-1397 URL: https://issues.apache.org/jira/browse/COUCHDB-1397 Project: CouchDB Issue Type: Bug Components: JavaScript View Server Affects Versions: 1.2.1 Environment: All Reporter: Jason Smith New SpiderMonkey releases do not eval() a sole anonymous function expression. That is not a valid JavaScript statement, and so it is not a valid JavaScript script. COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for 1.2. (Sorry to spam COUCHDB-1302. I saw Unassigned and read Unresolved.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
[ https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13199838#comment-13199838 ] Paul Joseph Davis commented on COUCHDB-1397: Firstly, I'm not thinking of eval, I'm thinking of JS_CompileScript/JS_CompileUCScript which is where this restriction is actually applied. Secondly, I didn't say transforms are out of the question, I said they are heavily discouraged. The reason for discouraging them is because they break shit as demonstrated by all the people that wrote in to tell me I broke shit with the simple paren wrapping approach not to mention that this is the sort of engineering that leads to SQL injection. Just because it's the easy answer for some folks doesn't necessarily mean its the right call. Function expressions, evals in SpiderMonkey --- Key: COUCHDB-1397 URL: https://issues.apache.org/jira/browse/COUCHDB-1397 Project: CouchDB Issue Type: Bug Components: JavaScript View Server Affects Versions: 1.2.1 Environment: All Reporter: Jason Smith New SpiderMonkey releases do not eval() a sole anonymous function expression. That is not a valid JavaScript statement, and so it is not a valid JavaScript script. COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for 1.2. (Sorry to spam COUCHDB-1302. I saw Unassigned and read Unresolved.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
[
https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13199892#comment-13199892
]
James Howe commented on COUCHDB-1397:
-
The string function(doc) {} *isnt* invalid JavaScript - it's just a string.
It only becomes an anonymous function at global scope if you pass it directly
to eval().
Function expressions, evals in SpiderMonkey
---
Key: COUCHDB-1397
URL: https://issues.apache.org/jira/browse/COUCHDB-1397
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 1.2.1
Environment: All
Reporter: Jason Smith
New SpiderMonkey releases do not eval() a sole anonymous function expression.
That is not a valid JavaScript statement, and so it is not a valid JavaScript
script.
COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for
1.2. (Sorry to spam COUCHDB-1302. I saw Unassigned and read Unresolved.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
[
https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13199904#comment-13199904
]
Benoit Chesneau commented on COUCHDB-1397:
--
Having a json which would do { views: name: { map: function map(doc)
{}}} is somehow inelegant and redundant imo.
The other solution { views: name: function map(doc) {} .. function
reduce(doc) {} } may be confusing:
- I can introduce the idea that people could share vars between this functions,
while they are used at different states. For example what would happen if
smeone shatre the results of the map function to the reduce function.
- Since these functions are used at different steps, why sharing them in the
same member ?
I think it may be better to keep the current split in different properties of
the design doc. I like the idea of elasticsearch to just pass script with a
global context inside.
we could have something like:
map = some script which could base a Ctx object containing all the neded
info:
ctx.doc
ctx.ddoc ...
then tue script could just return or emit.
What do you think?
Function expressions, evals in SpiderMonkey
---
Key: COUCHDB-1397
URL: https://issues.apache.org/jira/browse/COUCHDB-1397
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 1.2.1
Environment: All
Reporter: Jason Smith
New SpiderMonkey releases do not eval() a sole anonymous function expression.
That is not a valid JavaScript statement, and so it is not a valid JavaScript
script.
COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for
1.2. (Sorry to spam COUCHDB-1302. I saw Unassigned and read Unresolved.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
[ https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13200071#comment-13200071 ] Paul Joseph Davis commented on COUCHDB-1397: @Benoit That's what I was trying to describe earlier. The draw backs that come to mind is that it's quite a break with the current behavior (and harder to detect the difference) and we'd probably want to add some sort of context member that is compiled and executed once when the map or reduce is run (only once for maps, and once per reduce call). Or we can just force people to abuse the commonjs cache maybe? Function expressions, evals in SpiderMonkey --- Key: COUCHDB-1397 URL: https://issues.apache.org/jira/browse/COUCHDB-1397 Project: CouchDB Issue Type: Bug Components: JavaScript View Server Affects Versions: 1.2.1 Environment: All Reporter: Jason Smith New SpiderMonkey releases do not eval() a sole anonymous function expression. That is not a valid JavaScript statement, and so it is not a valid JavaScript script. COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for 1.2. (Sorry to spam COUCHDB-1302. I saw Unassigned and read Unresolved.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
[
https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13198732#comment-13198732
]
Jason Smith commented on COUCHDB-1397:
--
## Facts
1. All documentation, all books, all online resources, and almost all code use
the function expression style to program CouchDB:
{ views:{people:{map:
function(doc) { emit(doc.name, 1) }
}}}
2. The code in the string is an invalid JavaScript statement, and also an
invalid program.
3. (Computer scientists, divert your gaze!) The code is a valid expression, or
perhaps an r-value. You can copy and paste it to the right-hand side of an
assignment statement, or paste it as a parameter in a function call.
4. CouchDB inadvertently exploited a now-fixed SM bug where you can just eval()
the expression, it is treated as a statement, and eval returns the compiled
function object.
5. Distinct from Fact 4, CouchDB users inadvertently exploited the bug by
writing what are more properly called programs, with helper functions, and a
final (incorrect JavaScript) function expression serving as the entry point for
Couch to call into.
6. There may be, if the community wants, a distinction between valid
*JavaScript* programming and valid *CouchDB* programming.
## Opinions
Those clever anonymous function expressions are relaxing. They make intuitive
sense. Learning how map/reduce works is one of the major emotional payoffs
CouchDB provides to a learner.
Asking the wiki maintainers, the book authors, and the CouchDB users to change
anything, even one character, is not relaxing, major release or no.
Instead we should ask something else:
1. CouchDB should support the same old same-old. Even on newer SpiderMonkey.
2. People who wrote full-on programs (helper functions, global state, etc.)
must adhere to the longstanding documentation and change their code. Perhaps
CouchDB or its community might show how.
Finally, unless someone can show otherwise, we should assume that very few
people wrote *programs* instead of *expressions* and so CouchDB can justifiably
start throwing errors on their code in the 1.2.x branches.
Function expressions, evals in SpiderMonkey
---
Key: COUCHDB-1397
URL: https://issues.apache.org/jira/browse/COUCHDB-1397
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 1.2
Environment: All
Reporter: Jason Smith
New SpiderMonkey releases do not eval() a sole anonymous function expression.
That is not a valid JavaScript statement, and so it is not a valid JavaScript
script.
COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for
1.2. (Sorry to spam COUCHDB-1302. I saw Unassigned and read Unresolved.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
[
https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13198936#comment-13198936
]
Paul Joseph Davis commented on COUCHDB-1397:
Describing this as exploiting a bug is incorrect. SpiderMonkey had a
non-standard extension to JavaScript that allowed for this syntax to be
considered valid. It was enabled by default.
Recent SpiderMonkey trunk has removed this option so it is no longer an error.
The logic underneath is interesting in that it has to specifically check for
this condition (ie, its completely valid except for a single is anonymous
function as statement check.
The nicest (and probably least likely) solution would be for SpiderMonkey to
add this option back but just disable it by default. I asked the SM team in IRC
shortly after we found the issue and they expressed a very negative view of
this approach so I doubt it's a possibility.
For reference, Jason's example:
{ views:{people:{map:
function(doc) { emit(doc.name, 1) }
}}}
And a fixed example that could work (with modifications to couchjs):
{ views:{people:{map:
function map(doc) { emit(doc.name, 1) }
}}}
and alternatively:
{ views:{people:{map:
var map = function(doc) { emit(doc.name, 1) }
}}}
We can upgrade couchjs to accept either form quite easily. I think a reasonable
plan would be to have a version of couchjs that accepts both and logs a
deprecation warning about the old version. Then we just need to go on a PR
campaign to get everyone to make the upgrade so they're prepared for when their
code eventually needs to run on a newer SpiderMonkey.
Also, I'm not convinced that this needs to be in 1.2. We still have a bit of
time to prepare a 1.2.1 that includes this. 1.2 should've been out a long time
ago and I'd rather we focus on getting that out and then worrying about this
afterwards since we have a plausible backwards compatible upgrade path.
Function expressions, evals in SpiderMonkey
---
Key: COUCHDB-1397
URL: https://issues.apache.org/jira/browse/COUCHDB-1397
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 1.2
Environment: All
Reporter: Jason Smith
New SpiderMonkey releases do not eval() a sole anonymous function expression.
That is not a valid JavaScript statement, and so it is not a valid JavaScript
script.
COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for
1.2. (Sorry to spam COUCHDB-1302. I saw Unassigned and read Unresolved.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
[
https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13199425#comment-13199425
]
Jason Smith commented on COUCHDB-1397:
--
Paul, tl;dr: I see your point but disagree because I love the old syntax. I
also have a fixed JS server (i.e. the code couchjs runs) working in all (IMO)
important cases. Would you care to at least see the patch?
Next I continue my plea to retain CouchDB's aesthetic decency...
After years of a relaxing API, why would CouchDB force us to stop writing
perfectly valid functions and instead write valid programs? It is redundant. It
is confusing. There is no obvious benefit to the user. It is Kafkaesque.
The current syntax that better matches our mental model is this:
{ views: {
example: {
map: function(doc) { emit(1, 2) }
...
That is intuitively relaxing because it feels like Javascript:
doc =
{views: {
example: {
map: function(doc) { emit(1, 2) }
...
Please re-read your own examples. How many new ways does it confuse the user?
And for what? Because we can't' be bothered to do anything except the simplest
possible implementation: just run it through eval(). What about this view
object:
Map: function map(D) { emit(1,D) } // wrong JSON key
map: function mapo(D) { emit(1, D) } // fat-fingered the function name
Really, if CouchDB will insist that users begin writing *programs* and not just
expressions, it makes more sense to eradicate the map and reduce fields and
replace the whole object with a string.
{views: {
people:
function map(D) {
emit(D.name, 1)
}
function reduce(K, V, re) {
return sum(K)
}
}
}
OTOH, given a previously well-formed view definition and newer SpiderMonkey,
couchjs should DTRT, do what it takes to make it work, as the user has already
begun relaxing.
Function expressions, evals in SpiderMonkey
---
Key: COUCHDB-1397
URL: https://issues.apache.org/jira/browse/COUCHDB-1397
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 1.2
Environment: All
Reporter: Jason Smith
New SpiderMonkey releases do not eval() a sole anonymous function expression.
That is not a valid JavaScript statement, and so it is not a valid JavaScript
script.
COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for
1.2. (Sorry to spam COUCHDB-1302. I saw Unassigned and read Unresolved.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
[ https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13199461#comment-13199461 ] max ogden commented on COUCHDB-1397: another option is to require commonjs instead of eval() and then just prepend module.exports = to the existing syntax. then you're using the same module syntax as the rest of the server side javascript world Function expressions, evals in SpiderMonkey --- Key: COUCHDB-1397 URL: https://issues.apache.org/jira/browse/COUCHDB-1397 Project: CouchDB Issue Type: Bug Components: JavaScript View Server Affects Versions: 1.2.1 Environment: All Reporter: Jason Smith New SpiderMonkey releases do not eval() a sole anonymous function expression. That is not a valid JavaScript statement, and so it is not a valid JavaScript script. COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for 1.2. (Sorry to spam COUCHDB-1302. I saw Unassigned and read Unresolved.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
[ https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13199503#comment-13199503 ] Jason Smith commented on COUCHDB-1397: -- Love it. I'd still rather that Couch supports the same old syntax as always, but if we must start writing full-on scripts, CommonJS is the wisest direction. Function expressions, evals in SpiderMonkey --- Key: COUCHDB-1397 URL: https://issues.apache.org/jira/browse/COUCHDB-1397 Project: CouchDB Issue Type: Bug Components: JavaScript View Server Affects Versions: 1.2.1 Environment: All Reporter: Jason Smith New SpiderMonkey releases do not eval() a sole anonymous function expression. That is not a valid JavaScript statement, and so it is not a valid JavaScript script. COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for 1.2. (Sorry to spam COUCHDB-1302. I saw Unassigned and read Unresolved.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
