These are chat archives for dry-rb/chat

21st
Dec 2015
Piotr Solnica
@solnic
Dec 21 2015 12:33 UTC
dryrb/dry-validation@0955118 <= this /c @cmrichards
after this addition your example can be written like that:
class BarcodeSchema < Dry::Validation::Schema::Form
  key(:barcode) do |barcode|
    barcode.none? | barcode.filled?
  end

  key(:job_number) do |job_number|
    job_number.none? | job_number.int?
  end

  key(:sample_number) do |sample_number|
    sample_number.none? | sample_number.int?
  end

  rule(:barcode_only) do
    rule(:barcode).filled? ^ (rule(:job_number).int? | rule(:sample_number).int?)
  end
end
notice that now you can compose higher level rules using specific predicates
Chris Richards
@cmrichards
Dec 21 2015 12:35 UTC
Yes, it looks better now
Piotr Solnica
@solnic
Dec 21 2015 12:35 UTC
this pretty much means we can easily specify validations that are strictly about type-safety and a separate set of higher level rules that rely on existing validation results
Chris Richards
@cmrichards
Dec 21 2015 12:35 UTC
Shouldn't the last | be a & ?
Piotr Solnica
@solnic
Dec 21 2015 12:36 UTC
no, because from what I remember you wanted to check if barcode is present only if both job number and sample number are empty
you could express it like that too: rule(:barcode).filled? & (rule(:job_number).none? & rule(:sample_number).none?)
I just wanted to use the new fancy xor :joy:
Chris Richards
@cmrichards
Dec 21 2015 12:38 UTC
Agreed :-)
Piotr Solnica
@solnic
Dec 21 2015 12:38 UTC
it feels good, I gotta say, you don’t need to mix lower level checks with higher-level stuff
I’m gonna work on documentation now and push 0.4.0 later today
Chris Richards
@cmrichards
Dec 21 2015 12:44 UTC
key(:barcode) do |the_barcode|
Is the_barcode actually rule(:barcode) ?
Piotr Solnica
@solnic
Dec 21 2015 12:52 UTC
no, rule(:barcode) returns a check-rule builder object
and the_barcode in the key block is a value-rule builder object
Piotr Solnica
@solnic
Dec 21 2015 14:49 UTC
@AMHOL I’m thinking about dry-v wiki structure, got some ideas what should be described apart from obvious stuff like specific features and syntax?
Andy Holland
@AMHOL
Dec 21 2015 16:18 UTC
Think stuff like concept, i.e. predicate logic and the flexibility that comes with it?
Also the difference between type validation and domain validation
Piotr Solnica
@solnic
Dec 21 2015 16:19 UTC
hm yeah, feels like this kind of info is needed
Tim Riley
@timriley
Dec 21 2015 20:54 UTC
πŸ‘πŸ»πŸ‘πŸ»
This type coercion / higher-level logic separation seems smart.
Piotr Solnica
@solnic
Dec 21 2015 21:13 UTC
@timriley :) it was kind of an epiphany for me the other day
Tim Riley
@timriley
Dec 21 2015 22:18 UTC
Also kind of paves the way for where your separation would lie if you had some HTTP Params validation at boundary, vs more domain-specific validation deeper in your app.