3 ms·

While this article hits on a very true aspect of validation, I think the real problem that needs to be solved is a bit deeper: There are really four levels of

While this article hits on a very true aspect of validation, I think the real problem that needs to be solved is a bit deeper: There are really four levels of validity that we care about: 1) absolutely invalid data that indicates an unanticipated system error 2) invalid data that the caller (or user) must fix. 3) invalid data that the caller/user can optionally fix but that we wish to warn about (via UX or in the log) 4) invalid data that is optional and so can be made valid by deleting it. I have not yet seen a system based on types/typing that elegantly captures the four cases above. ActiveRecord validations feels like an antipattern because it is in some ways weaker than typing, but in some cases more flexible. So we typically resort to ad-hoc approaches that are essentially custom code doing the same thing in many projects. ActiveRecord validations removes boilerplate and makes it easy to give user feedback for simple flat object structures with predictable semantics and low probability of logic errors. This changes with nested structures. I wonder if it would be possible to do something along the lines of the Maybe monad to handle scenarios 1-4 above via pattern matching...

solnic 11y ago
This is exactly what I'm trying to solve with both dry-validation and dry-data. I wouldn't agree with the low probability of logic errors in AR validations though. I think a DSL with lots of options is a recipe for logic errors. This is the reason why I decided to use predicate logic as the base for dry-validation. It supports nested structures easily, it also supports defining high level rules that rely on results from low-level rules (typically type checking with additional constraints, who would have thought ;)). I'd love to know more about your idea for using Maybe monad in validations. Using pattern matching crossed my mind more than once but so far I haven't seen a real need for it (in dry-validation). This is an awesome comment btw. These 4 points describes this problem in a very clear way. It's such a fundamental problem and I believe people should have a good understanding of what it involves. There's one thing I'd add to this - coercion logic. It's very common that you need to coerce values coming from "the outside", and there are different rules for coercions depending on the context. That's why in dry-data you have different coercible type categories and "form" category is dedicated for web forms.
- encoderer 11y ago
  I think the coercion you talk about is a mapping that should take place outside the object. I would love to see a validation library like yours made for Django.
DanielBMarkham 11y ago
Yes, this gets directly to something like a "philosophy of operations" that everybody using the code has to know and agree on. Don't think there's a universal answer; multiple paths yield acceptable results.

solnic 11y ago

This is exactly what I'm trying to solve with both dry-validation and dry-data. I wouldn't agree with the low probability of logic errors in AR validations though. I think a DSL with lots of options is a recipe for logic errors. This is the reason why I decided to use predicate logic as the base for dry-validation. It supports nested structures easily, it also supports defining high level rules that rely on results from low-level rules (typically type checking with additional constraints, who would have thought ;)). I'd love to know more about your idea for using Maybe monad in validations. Using pattern matching crossed my mind more than once but so far I haven't seen a real need for it (in dry-validation). This is an awesome comment btw. These 4 points describes this problem in a very clear way. It's such a fundamental problem and I believe people should have a good understanding of what it involves. There's one thing I'd add to this - coercion logic. It's very common that you need to coerce values coming from "the outside", and there are different rules for coercions depending on the context. That's why in dry-data you have different coercible type categories and "form" category is dedicated for web forms.

encoderer 11y ago
I think the coercion you talk about is a mapping that should take place outside the object. I would love to see a validation library like yours made for Django.

DanielBMarkham 11y ago

Yes, this gets directly to something like a "philosophy of operations" that everybody using the code has to know and agree on. Don't think there's a universal answer; multiple paths yield acceptable results.