@blelump I added my point to the discussion there, right now I think it's hard to fully integrate dry-v with reform, some key underlying key concepts seems divergent. The validation side of dry-v could still be used without a problem I think, but reform would still do everything else.

And as I put in the end of my comment, maybe we just need a forked reform that rework the internals to better integrate some of the dry-rb gems. As right now dry-types and dry-validation overlap with reform on what they can do.

Caveat: @solnic , would it be possible that dry-v eats object and checks rules against object instead of a hash? In such case, I would be able to pass e.g an OpenStruct object, e.g. schema.(OpenStruct.new({name: 1})). That would significantly simplify Reform validation process. It would even handle coercions inferring and that would be a blast :smile: . What do you think? Is object state mutation not too much here?

I believe the way dry-v should be used is shown best in formalist, where data validation appears first and then, upon the result and form "schema", the AST is being built. The same I think about Reform. However, Reform is built with a concept of twins, where each twin object is just a twin of the real model in AR and essentially, any thing you may want to perform before persistence state, is going to be performed on twin, not the real model. Validation process is also fired against twins

I asked about validating objects and what @AMHOL tried to clarify to me, because Reform validates objects. However it's possible to serialize it to hash with primitives, I feel this is not right since there're already built object graph (twins)