and there are opportunities for more optimization there
I also imagine that, for dry-v and dry-t, the more that can be expressed using dry logic the better (barring big perf hits)
ok folks I’m done with logic/validation stuff…I’d appreciate if you could add this:
gem 'dry-validation', github: 'dry-rb/dry-validation', branch: 'master'
gem 'dry-types', github: 'dry-rb/dry-types', branch: 'master'
gem 'dry-struct', github: 'dry-rb/dry-struct', branch: 'master'
gem ‘dry-logic’, github: 'dry-rb/dry-logic', branch: 'master'to your Gemfile and run your tests…
@fran-worley hey! could you tell me if latest stuff from master works fine with Reform and friends?
@solnic according to that issue the dependency then should be remove from the Gemfile? I mean by optional you mean that the user will install the dependency by itself ?
s/itself/himself
@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)