These are chat archives for dry-rb/chat

2nd
May 2016
Nikita Shilnikov
@flash-gordon
May 02 2016 08:00
@timriley do you know if we should do anything prior to push dry-monads to rubygems?
Tim Riley
@timriley
May 02 2016 09:13
@flash-gordon Feels like things are ready for a first release, yep. I’d be happy for you to push! We should double check the PR for the dry-rb.org docs, too, just to make sure they’re still valid, and we can make them live shortly after.
@flash-gordon I might have worked out the issue with CodeClimate’s coverage reporting. Going to do a push to master in a sec.
The issue was that simplecov et al need to be set up before the gem’s own source files are included.
Nikita Shilnikov
@flash-gordon
May 02 2016 09:20
@timriley you're awesome!
actually I tried something like that but it didn't work
I even dumped codeclimate report to a file and it was OK, I mean method definition lines were covered
weird
Andrew Kozin
@nepalez
May 02 2016 12:47
how could I define a validation rule like key(:quantity) { filled? & gteq?(1) }, but to be applied lazily (not to check the second rule if the first is broken)?
Benjamin Klotz
@tak1n
May 02 2016 12:48
key(:quantity).required

rule(quantity_rule: [:quantity]) do |quantity|
  quantity.filled?.then(quantity.gteq?(1))
end
not sure if there is a better way :)
Andrew Kozin
@nepalez
May 02 2016 12:52
no, this works not in a way I need. It will return true when quantity is not filled
I wonder whether we need predicates that work like && and ||. I see the reason why & and | work in a way they do, but lazy comparison is missed for now, isn't it?
Tim Riley
@timriley
May 02 2016 12:57
@nepalez does this do what you want?
Andrew Kozin
@nepalez
May 02 2016 12:57
@timriley let I guess. Two rules instead of one?
Tim Riley
@timriley
May 02 2016 12:58
schema = Dry::Validation.Schema do
  key(:qty) { filled? > gteq?(1) }
end

schema.(qty: 5)
# => #<Dry::Validation::Result output={:qty=>5} messages={}>

schema.(qty: nil)
# => #<Dry::Validation::Result output={:qty=>nil} messages={}>

schema.(qty: 0)
# => #<Dry::Validation::Result output={:qty=>0} messages={:qty=>["must be greater than or equal to 1"]}>
Andrew Kozin
@nepalez
May 02 2016 12:58
nope
Tim Riley
@timriley
May 02 2016 12:59
I must not understand what you want then :grimacing:
Andrew Kozin
@nepalez
May 02 2016 12:59
This one does the work:
schema = Dry::Validation.Schema do
  key(:qty) { filled? > qteq?(1) }
  key(:qty) { filled? }
end
Tim Riley
@timriley
May 02 2016 12:59
ah, sorry, I was thinking you didn’t want the second predicate to apply if the first failed, not another rule
Andrew Kozin
@nepalez
May 02 2016 13:00
But I'd like key(:qty) { filled? && qteq?(1) } instead of two
Benjamin Klotz
@tak1n
May 02 2016 13:00
require 'dry/validation'

schema = Dry::Validation.Schema do
  key(:quantity).required

  rule(quantity_rule: [:quantity]) do |quantity|
    quantity.filled?.then(quantity.gteq?(1))
  end
end

schema.call({ quantity: nil })
{:quantity=>["must be filled"]}

schema.call({ quantity: 0 })
{:quantity=>["must be greater than or equal to 1"]}

schema.call({ quantity: 5 })
{}
Tim Riley
@timriley
May 02 2016 13:01
^ nice
Andrew Kozin
@nepalez
May 02 2016 13:02
@tak1n yeah, your rules are the same as mine
Benjamin Klotz
@tak1n
May 02 2016 13:02
@nepalez yep but you're solution has lesser lines :D
Andrew Kozin
@nepalez
May 02 2016 13:03
still one line longer than I'd like
Benjamin Klotz
@tak1n
May 02 2016 13:03
yep like the idea you have
Tim Riley
@timriley
May 02 2016 13:05
OK, how about this?
schema = Dry::Validation.Schema do
  key(:qty) { filled? & (filled? > gteq?(1)) }
end

schema.(qty: 5)
# => #<Dry::Validation::Result output={:qty=>5} messages={}>

schema.(qty: nil)
# => #<Dry::Validation::Result output={:qty=>nil} messages={:qty=>["must be filled", "must be greater than or equal to 1"]}>

schema.(qty: 0)
# => #<Dry::Validation::Result output={:qty=>0} messages={:qty=>["must be greater than or equal to 1"]}>
Andrew Kozin
@nepalez
May 02 2016 13:09
@timriley yeah, this workaround is one-line... but what if we have more parts:
key(:qty) { filled? & (filled? > gteq?(1)) & (filled? > gteq?(1) > lteq?(10)) }
looks awful
Tim Riley
@timriley
May 02 2016 13:09
That schema above is equivalent to the following, btw:
schema = Dry::Validation.Schema do
  key(:qty).required(gteq?: 1)
end
Sure, you might say that looks awful, but how else would you model it?
Andrew Kozin
@nepalez
May 02 2016 13:12

What I do want is to have

schema.(qty: nil)
# => #<Dry::Validation::Result output={:qty=>nil} messages={:qty=>["must be filled"]}>

instead of

schema.(qty: nil)
# => #<Dry::Validation::Result output={:qty=>nil} messages={:qty=>["must be filled", "must be greater than or equal to 1"]}>
Tim Riley
@timriley
May 02 2016 13:13
I believe that providing the latter was an intentional decision, since it gives the user more information about what exactly will be expected of that value once the “filled” requirement is satisfied.
But IIRC solnic was planning to do more work on the error compiler, too.
Andrew Kozin
@nepalez
May 02 2016 13:14
but in june ;)
Tim Riley
@timriley
May 02 2016 13:14
no earlier :)
Andrew Kozin
@nepalez
May 02 2016 13:18
actually the problem is not with the error compiler, but with predicates. IMO we need predicates that stop making unnecessary checks
Tim Riley
@timriley
May 02 2016 13:19
Those latter predicates in my example aren’t actually being run, as far as I can tell.
They just exist in the AST of rules, which the error compiler can use to make helpful error messages.
I’m interested - why is it that you want to withhold this error message information?
Andrew Kozin
@nepalez
May 02 2016 13:22
schema.call(qty: nil)                                                                                                                                                                                                          
=> #<Dry::Validation::Result output={:qty=>nil} messages={:qty=>["must be filled", "must be greater than or equal to 1"]}>
This mean both checks were made. I want not to withold the result of the second check. I'd like not to do it in case of the first one failed
Tim Riley
@timriley
May 02 2016 13:23
But "must be greater than or equal to 1” is still a valid (and helpful!) error message in this case...
And it’s not actually running gte? method, that’s what I was saying before. If the filled? predicate fails, then none of the subsequent predicates will actually be executed.
But it knews from the rules AST that those predicates would be run if filled? did happen to succeed, so it provides error messages about them so the user can know what kind of value should be provided.
Otherwise they can make mistakes multiple times over.
“It needs to be filled? OK, let me enter ‘0’. Oh, that failed too. Now I see it needs to be greater than 1.”
Andrew Kozin
@nepalez
May 02 2016 13:26
But (1) it costs additional computation, (2) it makes me worry about correctness (add protection from possible nil or type-mismatch etc.)
Tim Riley
@timriley
May 02 2016 13:26
The latter predicates are not being executed.
Andrew Kozin
@nepalez
May 02 2016 13:26
Ahh!
I got it
Yeah, thank you - this seems exactly what i need
Tim Riley
@timriley
May 02 2016 13:27
Cool, that’s great :)
Tim Riley
@timriley
May 02 2016 13:43
Here’s the draft for this week’s blog post, introducing dry-{container,auto_inject,component}. Would appreciate any feedback!
Luca Guidi
@jodosha
May 02 2016 14:04
Hi folks, before I flood GH Issues with other tickets, I want to check w/ you what to expect from the semantic of dry-v maybe .
Form: optional(:foo).maybe(eql?: '23'), when I do result = form.call('foo' => ''); puts result.success?, it returns true, but shouldn't it be false?
Tim Riley
@timriley
May 02 2016 14:24
@jodosha i think the behaviour youre seeing is actually correct, maybe(predicates) expands out to "is blank OR <predicates>"
so the "" is satisfying that "is blank/empty" part of the rule, so the other predicates never run
I'm just about to disappear (:zzz: time for me), but i hope that helps a little!
Luca Guidi
@jodosha
May 02 2016 14:26

@timriley

so the "" is satisfying that "is blank/empty" part of the rule, so the other predicates never run

Is this an explanation of the problem?

Tim Riley
@timriley
May 02 2016 14:26
Its
I was trying to explain why success? => true for your d amp
your example
(sorry, gitter is hard on ipad!)
Luca Guidi
@jodosha
May 02 2016 14:27
@timriley Sure, just wanted to be sure if it was a diagnosis or explanation of my wrong expectation. Thanks for this clarification!
Tim Riley
@timriley
May 02 2016 14:27
Its not actually a problem as far as i can see - if you dont want that behaviour, you can use filled instead of maybe, cant you?
ah, cool cool :)
Gnight! I'll see if I can help with some of your GH issues in th morning.
Luca Guidi
@jodosha
May 02 2016 14:28
@timriley I'm testing a combination of required/optional with value/filled/maybe. So for each predicate we have 6 cases for a given value
Tim Riley
@timriley
May 02 2016 14:29
Right, that makes sense.
Luca Guidi
@jodosha
May 02 2016 14:29
@timriley These tests are run against Schema and Form. So, I'm not judging the eventual usage, just tracking what's the outcome.

@timriley

if you dont want that behaviour, you can use filled instead of maybe, cant you?\n\n\n
That was a reply to this. I can't control what developers want to do. Anyway that behavior looks like a bug.

@timriley Is it fine if I open a ticket for each failure? Just tell me what's best for dry-v repo
Tim Riley
@timriley
May 02 2016 14:31
I think individual tickets are good. Ensures nothing gets missed by accident.
Luca Guidi
@jodosha
May 02 2016 14:33
@timriley :+1: thank you
Laura Williams
@lauraannwilliams
May 02 2016 21:38
Hello - hopefully quick question. Is there an example of a custom predicate for dry-validation that takes a value
For example, if i wanted to validate size?(10) with a custom predicate
Tim Riley
@timriley
May 02 2016 23:08
@lauraannwilliams it’s a bit like the top example of http://dry-rb.org/gems/dry-validation/custom-predicates/, but instead of def predicate_name?(input), it’d be def predicate_name?(arg, input)
where arg is what you pass to it in the schema, e.g. 10 for your size?(10) example
:joy:
Don Morrison
@elskwid
May 02 2016 23:54
:rimshot:
Don Morrison
@elskwid
May 02 2016 23:56
Is it tacky to rimshot twice? Been a while since I was in a band.
Hunter Madison
@hmadison
May 02 2016 23:56
no idea
Don Morrison
@elskwid
May 02 2016 23:56
ha
Tim Riley
@timriley
May 02 2016 23:57
@hmadison would you happen to have invitations to lobsters?
Hunter Madison
@hmadison
May 02 2016 23:57
sure pm me whatever email you use for these sorts of thigns
*things
Tim Riley
@timriley
May 02 2016 23:57
Ta!
Hunter Madison
@hmadison
May 02 2016 23:57
np
Don Morrison
@elskwid
May 02 2016 23:59
@timriley all joking aside - I’ve appreciated you writing up your thoughts and findings in regards to using dry-rb gems.
Very helpful.