Prototype with multiresult#32
Prototype with multiresult#32brettz9 wants to merge 29 commits intoJSONPath-Plus:masterJSONPath-Plus/JSONPath:masterfrom brettz9:prototype-with-multiresultbrettz9/JSONPath:prototype-with-multiresultCopy head branch name to clipboard
Conversation
… use consistently use single quotes except where content includes double quotes
…ed arg (as per other patch); export class and deprecate exporting of singleton and class method (will probably allow for instance to avoid autostarting)
…ward compatibility. Having options first will allow separate calls for the object and expression to an evaluate method if autostarting is not desired
…method, "evaluate"
…s (clearer for readers of code)
…and deprecated syntaxes in docs; document properties and elaborate on syntax
…hes with sandbox-supplied vars; indicate object is private var.
…uiring "new" by avoided
…, not null (also change tests to check for strict equality since test was not catching this). Add a test to actually return null, a valid JSON value. Incorporate issue JSONPath-Plus#20 but with "all" instead of "both" as name to allow for other result types (e.g., I hope to add parent and property name). Stop returning false for falsy unwrapped (unless actually false) as could be null, a legitimate JSON value
|
@brettz9: Unfortunately, this is a backwards-incompatible change. Comments? |
|
I also suggest squashing comments before submitting a PR, so that the PR is just one single commit. Thanks. |
|
By backwards-incompatible, I guess you are referring to the fact that null will be returned instead of false when the value is actually an unwrapped null, and that undefined will be returned instead of false upon failure to find the path? I think these are really critical because without them, they limit the accuracy of what JSONPath can retrieve (i.e., legitimate null values) or distinguish between failures and actual false values. As this is a change in the library rather than the syntax, I think it is also less critical. But as it is backwards-incompatible in a sense, I think it would normally deserve a major version bump, but since you are still in version 0.x, semantic versioning allows you to simply increment the minor version 'x' for incompatible changes. As far as the comments, I guess you mean the multiple commits... Yeah, I'm sorry about that--I will try to provide more clean PRs... Also, I now realize I could install nodeunit myself, so relying on that for debugging over travis builds. But I also would think incremental changes were easier to follow (especially now that the whitespace and JSLint changes are out of the way). |
|
Closing in favor of #35 |
Provide own implementation of issue #20 on top of prototype commit, as well as some test improvements, and allowing for null as an unwrapped result.