These are chat archives for dry-rb/chat

7th
Feb 2017
Jonah
@jonahx
Feb 07 2017 00:01
@solnic, so if i have an Email type defined using format: and some other custom type like “SocialSecurityNumber” or whatever also defined using format, how would I distinguish between the errors? (Assuming the error message is just keyed on the generic format? key)
Piotr Solnica
@solnic
Feb 07 2017 00:07
depends on the use case, if they are used in structs, you’ll see which attribute failed
Jonah
@jonahx
Feb 07 2017 00:31
ok thx
Jonah
@jonahx
Feb 07 2017 07:29

@solnic so i’ve been thinking about custom domain objects and how they relate to validations all day, and i don’t know how hard this would be for you to implement (or if it’s already implemented and i suck at reading docs!), but i think my concerns would be answered it there was a way to specify a “self validating object” in the schema. eg, say I already have an Email object which will raise an error if I attempt to create an instance using a string which has no @. Then I could write:

required(:email).filled(valid_instance?: Email)

And, assuming input was called with input, the validation procedure would consist of running Email(input) inside of a begin…rescue block. If it ran without error, it would return the Email instance. Otherwise the raised error message would be used as the validation error message. Thoughts?

Jonah
@jonahx
Feb 07 2017 08:02
just one more thought before i crash. i could be convinced of pushing all error messages into a central location (yaml file or otherwise) and then having the domain objects like Email use that to get the error messages they need. so the second part of the above request is imo far less important than the first, and is only a convenience for small projects. the first part is pretty important imo, but i suspect there is a way to do it already somehow that i’m missing….
Piotr Solnica
@solnic
Feb 07 2017 08:16
@jonahx this type of functionality is not needed, constrained types can be used with dry-v and it’ll extract their constraints and use them for rules. using exceptions would be an overkill
Jonah
@jonahx
Feb 07 2017 08:21
@solnic you don’t think there would be a benefit to being able to use custom objects (that already contain validation and coercion logic) within the validations? or am i misunderstanding you?
for me this all comes down to avoiding any kind of lockin. not that i don’t like dry-types (i do), but i feel i should be able to levarage the logic contained within dry-validation using my own POROs if i feel like doing that.
Piotr Solnica
@solnic
Feb 07 2017 08:27
required(:email, Email) will do what you need but Email would have to encapsulate everything, so both coercion and rules
and it must be a dry-type type
Jonah
@jonahx
Feb 07 2017 08:29
@solnic so if I had an existing email object, i would need to need to wrap it as a dry-type in order to use it within a validation? what would be the mimimal interface i would need to implement to do so? are there docs on that?
Piotr Solnica
@solnic
Feb 07 2017 08:33
it would require defining a predicate that will rescue the exception and return false
but I never tried that
and yes, it would have to be wrapped in a dry-type object
Jonah
@jonahx
Feb 07 2017 08:34
@solnic ty. i will attempt it tomorrow and report back
passing out now, gn.
Piotr Solnica
@solnic
Feb 07 2017 08:34
sounds good, g’nite!
Sergey Kukunin
@Kukunin
Feb 07 2017 21:02
@solnic can you advice me good start point to understand AST and read #to_ast output more easily?