[
https://issues.apache.org/jira/browse/COUCHDB-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13122206#comment-13122206
]
Paul Joseph Davis commented on COUCHDB-1302:
--------------------------------------------
Ok. Here's the situation:
First, an anonymous function at the root of a scope is invalid JavaScript. Ie,
the following is invalid:
"function(doc) {emit(doc._id, 1);}"
Is broken JavaScript.
But, SpiderMonkey has had an option for years [1] that allowed this.
SpiderMonkey happened to be the only interpreter that has had this. The setting
JSOPTION_ANONFUNFIX existed to enforce the error mechanism. The thing is, it
was off by default (ie, the error was not triggered by default) in older js
shells.
Recently, this appears to have caused an error for SpiderMonkey passing the
JavaScript test suite [2]. Along with this patch, the js shell from SM 1.8.5
enables JSOPTION_ANONFUNFIX so all of the js shell tests we were doing were
misleading. couchjs works with the 1.8.5 tarball from Mozilla. It does not work
starting when [2] was applied to trunk (after the 1.8.5 tarball was created).
So bottom line, this isn't an issue for all of the tarballs from Mozilla's
official FTP site, but it will be an issue moving forward.
So the plan I'm proposing is this:
1. Re-enable support for 1.8.5 on 1.1.x for 1.1.1
2. Revert the paren hack across the board.
3. Add a configure check for JSOPTION_ANONFUNFIX so we can detect if
user code will break (and perhaps add an option to override it)
4. Update 1.2.x with some new behavior that will force people to upgrade
all of their function definitions to be correct moving forward. Also note
that
this would be backwards compatible if the named function is the last
statement
as we currently require which should be enforceable in the future (if we so
desire).
I think 1, 2, and 3 are relatively uncontroversial at this point. We now know
how to detect exactly when old code will break and can warn about it (ie, by
refusing to build, (the option to override I'm less certain about, I'd be +0.5
at this point)).
As to 4, the behavior I would propose at this point is that all of our JS
definitions would require a name in the future. For instance:
"function(doc) {emit(doc._id, 1);}"
becomes:
"function map(doc) {emit(doc._id, 1);}"
And then couchjs+main.js gets modified to look for these specific names. I'm
thinking we'd end up with "map", "reduce", "filter", "validate", "show",
"list", and "update" given our current set of user definable functions. For
users we'd also need to make our error messages better. Currently, the error
without these names would be something generic like "expression does not
evaluate to a function" or similar which could be change to something like "No
function named 'map'" or similar (though, that obviously needs work cause it
could be a real syntax error as well).
So, 1, 2, and 3 have my +1. I think 4 is probably best going forward, but we
can open a new ticket about how to deal with the it for 1.2.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=377433
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=665835
> Fix couchjs
> -----------
>
> Key: COUCHDB-1302
> URL: https://issues.apache.org/jira/browse/COUCHDB-1302
> Project: CouchDB
> Issue Type: Improvement
> Components: JavaScript View Server
> Affects Versions: 1.1.1, 1.2, 1.3
> Reporter: Paul Joseph Davis
> Priority: Blocker
>
> Figure out why some spidermonkeys have an error when doing:
> eval("function(){}")
--
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
