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
The discussion about regexp keys got me thinking about two other things that would be really useful:
Regexp validator
Add /regexp/ as a matching criteria, with the intended meaning that:
key: /regexp/
permits any string value whose undelimited form matches the regexp.
Procedure validator
Permit a lambda expression (val) => boolean as a matchable type, with the intended meaning that the boolean, number, [undelimited] string, list, or structure value read is passed to the function, and is accepted exactly if the function returns true. This enables some very interesting filtering without adding much complexity to the core implementation. In particular, it would enable a sophisticated matcher to implement things like:
Accept only specific number values
Check a structure using a (nested) yaml-validator, but then confirm that co-required keys or mutually-exclusive keys are not present.
Unfortunately, I suspect that either of these takes us past what check-type can do.
Thoughts?
The text was updated successfully, but these errors were encountered:
This would be definetly something that should be added, as it is very useful, but I am currently not actively using this for anything, hence asking if you would be willing to work on it?
The discussion about regexp keys got me thinking about two other things that would be really useful:
Regexp validator
Add /regexp/ as a matching criteria, with the intended meaning that:
permits any string value whose undelimited form matches the regexp.
Procedure validator
Permit a lambda expression (val) => boolean as a matchable type, with the intended meaning that the boolean, number, [undelimited] string, list, or structure value read is passed to the function, and is accepted exactly if the function returns true. This enables some very interesting filtering without adding much complexity to the core implementation. In particular, it would enable a sophisticated matcher to implement things like:
Unfortunately, I suspect that either of these takes us past what check-type can do.
Thoughts?
The text was updated successfully, but these errors were encountered: