You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the JSON comparison assertion public APIs are too permissive where they allow for any incoming types:
It's more confusing at the call site what types to use
It allows for known invalid comparisons (at the call site)
An immediate solution could be only allowing JSONObject == JSONObject and JSONArray == JSONArray comparisons as the API param types
A future looking solution could be something like creating a sealed class (that works like a union type) that can create a better type interface for mixing and matching types, especially if the feature of allowing custom validation start point paths is implemented
Additional implementation details or code snippet(s)
No response
The text was updated successfully, but these errors were encountered:
timkimadobe
added
the
task
Item that can be completed as a standalone code change or is part of an epic.Used by issue template
label
Oct 13, 2023
Task description
Currently the JSON comparison assertion public APIs are too permissive where they allow for any incoming types:
An immediate solution could be only allowing
JSONObject
==JSONObject
andJSONArray
==JSONArray
comparisons as the API param typesA future looking solution could be something like creating a sealed class (that works like a union type) that can create a better type interface for mixing and matching types, especially if the feature of allowing custom validation start point paths is implemented
Additional implementation details or code snippet(s)
No response
The text was updated successfully, but these errors were encountered: