The '-' accessor can be used with the replace operation

[ludoblues]

I don't know if it's against the rfc6902 specification, but it appears to be very usefull in many cases.

[bruth]

Can you provide examples for your claim? Why is it easier than [{op: 'replace', path: '/foo/3', value: 42}]?

[ludoblues]

When you work with different patchs (and not different operations within a single patch), you are not aware of the position of the last element you want to work on.

I use jsonpatch-js to apply rules to an object, i have a lot of rules which can be potentially applied to this same object.

A rule is basically composed by a filter and a patch. If the filter match with my object values, i apply the patch and check the next rule, if not, i only check the next rule.

After some rules, you can be interested by saying "ok now, if it matchs this specific filter, i want to replace the last element by this value".

But the situation i met which led me to this PR is this case: "i want to insert "this", but if the first element is "that", i rather want to insert "these", which can be achieve by this patch:

var patch = [
    { op: 'add', path: '/foo/-', value: { key: 2 } },
    { op: 'test', path: '/foo/0', value: { key: 3 } },
    { op: 'replace', path: '/foo/-', value: { key: 2, foo: bar }  }
];

[bruth]

Interesting approach. I presume this is easier than doing any kind of conditional testing on the object being patched? Do the objects being patched vary so much that this would be difficult?

[ludoblues]

Yes, initially, i didn't know anything about jsonpatch, and i built an implementation in full conditionnal javascript, it worked, but it was a mess to update (wich is also a need in my case).

The great think with jsonpatch in this case, is that every rules can be "independent" by being expressed in operations, so i just have to parse my collection of rules and apply every patchs to my object to get the expected final result.

If i start to mix conditional javascript algorithms and jsonpatch, i'll lose this philosophy. It wouldn't be SO difficult to implement anyway, but it would seriously impact the benefit of jsonpatch in my implementation.

[bruth]

I just found this! http://tools.ietf.org/html/rfc6902#appendix-A.16 which uses this syntax.

[bruth]

I got overly excited with the example only to realize it was for add. I still think applying this to for replace is useful, however my concern is that patches will be incompatible with other libraries that implement the spec.

[bruth]

Feel free to fork and modify for your needs, however I want to adhere to the specification so patches created across implementations remain compatible.