@cored hey, that's what @solnic told me: https://github.com/dry-rb/dry-validation/pull/238#issuecomment-244924977 :) I'm just gonna do a monkey-patch with opt-in
to_either method
so this case is trivial ^
so since some specs have a definition for an struct, I guess the check also will be there
@solnic, @backus backing up to your conversation earlier today ... In working on dry-rb/dry-validation#67 I wanted to provide a consistent api for discovering fields in a dry-v and a dry-s. Having both libraries use a more consistent schema interface would make this much cleaner. As it is right now I have to make dry-l look more like dry-v at the rule-ast level.
I'll be pushing some code to look at later today/tonight.
^^ unfortunate typo - should be: As it is right now I have to make dry-s look more like dry-v at the rule-ast level.
@rx I’m not entirely sure if it’s the best direction but we’ll see. rules are not for defining data structures, they are generic. We can easily add generating some meta-data in dry-v schemas though, or try to use generated dry-t’s schemas (that do define the structures). I think I mentioned that in the related issue :)
@solnic yes I started down that route but it started feeling like I was pushing the metadata requirements into both dry-v and dry-s, when the rules_ast already had everything that is needed (and more). This lead me to treating the metadata api more like an extension, like you mentioned earlier in the issue :smile: I translated dry-s rules-ast to dry-v rules-ast temporarily to allow me to start using the extension with dry-s. The next step is resolving the non-symmetrical dry-s and dry-v schemas, that would allow me to throw away my temporary dry-s(ast)->dry-v(ast) translation. This approach allowed me to build a more complete set of metadata for both dry-v and dry-s with minimal dependencies and saving anyone else from groking the underlying rules_ast. :smile: If the underlying rules_ast is likely to change more than the dry-s and dry-v object model then I did indeed take a wrong turn.
fwiw the ast approach is going to be the most powerful, so assuming it’s easy to translate it to what we need, this will be the best approach :)
Right now I'm putting this into its own repo as a WIP for you to look at.
btw - I had trouble finding a dry-v rules_ast set and not examples. Do you have one? And do you want me to open an issue or PR against the website documentation?
I built my specs using the documentation on the website.
(not sure why I’m smiling lol)
required(:admin) { true? | true?.not } == required(:admin) { true? | false? }
we could probably add support for
not(true?) though
it’d look better
:+1: on not(true?)
Would you like issues opened on the website for missing doc items?
thx!
@solnic will do
@solnic do you have an example of a dry-v 'set' off the top of your head?
it’s basically a list of rules that must be applied to the same input