Closed gregsdennis closed 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.
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.
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.
Fixed by 93e168e817b8b68a65f4ed41e61cf4134f9c54c5.
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 oflength()
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.)