ietf-wg-jsonpath / draft-ietf-jsonpath-base

Development of a JSONPath internet draft
https://ietf-wg-jsonpath.github.io/draft-ietf-jsonpath-base/
Other
59 stars 20 forks source link

Function overloads #430

Closed gregsdennis closed 1 year ago

gregsdennis commented 1 year ago

Ref: https://www.ietf.org/archive/id/draft-ietf-jsonpath-base-11.html#name-function-extensions-3

Currently there is no language that prevent someone from registering an overload of a function save for the experts' opinions on the matter.

For example, if I wanted to register a length() function that took a second or even a third parameter, I could do so. It would be sufficiently distinct to parse and determine which version of length() is being used.

Is this something we want to allow, or should we state explicitly that function names should be unique? (It would save a lot of coding effort on my part if they were unique.)

glyn commented 1 year ago

Another example would be registering a length() function that took a NodesType since the experts might decide that the closest type match wins (e.g. length(@.*) would bind to the new function whereas length(@.foo) would bind to the function in the draft).

I think we should rule all these possibilities out so that it's obvious to users when a particular function is being used. We should say that at most one entry in the sub-reqistry may have a given function name.

cabo commented 1 year ago

Definitely unique (i.e., we could allow overloading, but we don't, and we shouldn't).
There is indeed a weakness in the usual IANA considerations language in that the fact that a column is the (or a) key is implicit; we should make that explicit.

cabo commented 1 year ago

Or, in other words, adding possible argument types to a function (which is identified by a name) is a change of the registration for that name (which is very much possible, which is why we have a change controller), not a new registration.

glyn commented 1 year ago

Fixed by 93e168e817b8b68a65f4ed41e61cf4134f9c54c5.