Add support for reading attribute values about dry-validation

[SunnyMagadan]

Hi, @solnic and @AMHOL
I would like to contribute into your project. I like the idea and see it like a clean and promising replacement for activemodel validations. I've already started playing around with this feature and made some progress there. Please let me know if you are interested in any help here.

[AMHOL]

@SunnyMagadan had a look at your branch and it all looks good to me, if you submit a pull request @solnic can take a look/merge it. Always good to see people taking an interest/helping out, thanks. 😄

[SunnyMagadan]

🙇 Great! Keep doing.

[SunnyMagadan]

@solnic I have one question regarding this feature. How do you plan to deal with optional? Right now it uses Rule::Key with Implication under the hood https://github.com/dryrb/dry-validation/blob/master/lib/dry/validation/schema/definition.rb#L10. Also InputTypeCompiler uses :key for visit and or implication https://github.com/dryrb/dry-validation/blob/master/lib/dry/validation/input_type_compiler.rb#L57. We need to distinguish optional key and optional attr somehow.

[solnic]

@SunnyMagadan there is no such thing as an optional attribute, an optional key means a hash may, or may not include a given key. When we talk about validating a model, it means it does have attribute readers for specified attributes. In this case, saying attr(:foo) means a model must implement foo reader. You can just skip this for attributes, since an attr reader will return nil even when the ivar was never set, so one could easily write attr(:foo) { |foo| foo.none? | foo.int? } etc.

[solnic]

BTW feel free to open a PR early, even when it's not finished. We can collaborate on changsets easily etc :)

[SunnyMagadan]

True. It doesn't make sense to have optional attributes. Thank you. I'll open WIP PR soon. :)
Also, I've found that this feature requires changes in dry-data, because current version of InputTypeCompiler based on it and uses schema conversion into hash type. I see that dry-data supports struct, but it requires to define a separate class for this. This is not very efficient for cases when we need to define schema on the fly.

[solnic]

@SunnyMagadan let's focus on pure schema first w/o coercions. I need to think how to tackle this on the dry-data side. My initial thinking is that we don't want coercions on dry-validation side when you're validating an model, I would say the model should handle coercions instead.

[SunnyMagadan]

This issue can be closed since corresponding PR was already merged.