search

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

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

Type checking within `ValueType` #431

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-length-function-extension (but also applies to other ValueType parameters in functions).

Our type system only allows for checking that a value is passed to (e.g.) length(), although it does parenthetically say that the function expects an object, array, or string. However these JSON types are not part of the type system.

Is $[?length(10)>5] valid/well-typed?

length() says it takes an instance of ValueType, and 10 is certainly that, so I would guess that the path is valid/well-typed.

glyn commented 1 year ago

Ref: https://www.ietf.org/archive/id/draft-ietf-jsonpath-base-11.html#name-length-function-extension (but also applies to other ValueType parameters in functions).

Our type system only allows for checking that a value is passed to (e.g.) length(), although it does parenthetically say that the function expects an object, array, or string. However these JSON types are not part of the type system.

Please could you say where that parenthetic remark is. I don't see it in the definition of length().

Is $[?length(10)>5] valid/well-typed?

Yes.

length() says it takes an instance of ValueType, and 10 is certainly that, so I would guess that the path is valid/well-typed.

Correct.

gregsdennis commented 1 year ago

OH.... it's in the return type.

Parameters: ValueType Result: ValueType (unsigned integer or Nothing)

length(10) still feels weird.

I think I might add a more strictly typed parsing mode to my lib that will catch things like this, but I'm fine with it parsing by default.

glyn commented 1 year ago

Closing as I think we have a resolution.

cabo commented 1 year ago

OH.... it's in the return type.

Parameters: ValueType Result: ValueType (unsigned integer or Nothing)

length(10) still feels weird.

I think I might add a more strictly typed parsing mode to my lib that will catch things like this, but I'm fine with it parsing by default.

Well, unless you can predict at compile time that the value is no good, this is not about parsing. length(@.a) also would require the same warning, but at runtime.

If your APIs allow funneling warnings around, that is certainly an opportunity for one. I'd consider this a quality of implementation issue.

gregsdennis commented 1 year ago

I can detect that length(10) is invalid at parse time, yes. length(@.a) is not detectable.

This is more relevant for functions where explicit arguments (literals) will be supplied, like the regex in match(). I'd want to be sure that the argument is a string and possibly even a regex.

Again, I can hide this advanced detection under a default-off option.