These are chat archives for dry-rb/chat

15th
Jun 2016
Luca Guidi
@jodosha
Jun 15 2016 07:57
@timriley Nice stickers!
Lairan
@alex-lairan
Jun 15 2016 09:55
Hi here !
I have a question, when I execute http://dry-rb.org/gems/dry-validation/custom-predicates/ I get errors
Dry::Validation::MissingMessageError: message for email? was not found
Fran Worley
@fran-worley
Jun 15 2016 09:57
@alex-lairan as it states at the end of the page, you need to add a message for the custome predicate
Lairan
@alex-lairan
Jun 15 2016 09:58
Oh yea thank :D
I'm so stupid ^^
Fran Worley
@fran-worley
Jun 15 2016 10:57
@solnic did you expect these to start failing?
rspec ./spec/integration/schema/using_types_spec.rb:44 # Dry::Validation::Schema defining schema using dry types fails when sum-type rule did not pass
rspec ./spec/integration/schema/using_types_spec.rb:36 # Dry::Validation::Schema defining schema using dry types correctly responds to messages
rspec ./spec/integration/schema/using_types_spec.rb:25 # Dry::Validation::Schema defining schema using dry types passes when input is valid
rspec ./spec/integration/schema/using_types_spec.rb:30 # Dry::Validation::Schema defining schema using dry types fails when input is not valid
rspec ./spec/integration/schema/using_types_spec.rb:66 # Dry::Validation::Schema defining schema using dry types structs handles nested structs
rspec ./spec/integration/schema/using_types_spec.rb:70 # Dry::Validation::Schema defining schema using dry types structs fails when input is not valid
rspec ./spec/integration/schema/using_types_spec.rb:86 # Dry::Validation::Schema defining schema using dry types custom coercions applies custom types to input prior validation
rspec ./spec/integration/schema/using_types_spec.rb:103 # Dry::Validation::Schema defining schema using dry types custom types applies custom types to input prior validation
Piotr Solnica
@solnic
Jun 15 2016 10:57
@fran-worley uhm, no it’s green over here
make sure you’ve got latest-and-greatest dry-types/logic from master
Fran Worley
@fran-worley
Jun 15 2016 10:59
yup that would be it. my bad :blush:
except now I get these two:
rspec ./spec/integration/schema/predicates/array_spec.rb:216 # Predicates: Array as macro with required when using an input_processor with nil input is not successful
rspec ./spec/integration/schema/predicates/array_spec.rb:224 # Predicates: Array as macro with required when using an input_processor with blank input is not successful
Failures:

  1) Predicates: Array as macro with required when using an input_processor with nil input is not successful
     Failure/Error: processed_input = input_processor[input]

     NoMethodError:
       undefined method `map' for nil:NilClass
       Did you mean?  tap
     # /Users/francesworley/.rvm/gems/ruby-2.3.0/bundler/gems/dry-types-861c0b2619a2/lib/dry/types/array/member.rb:13:in `call'
     # /Users/francesworley/.rvm/gems/ruby-2.3.0/bundler/gems/dry-types-861c0b2619a2/lib/dry/types/hash/schema.rb:15:in `block in call'
     # /Users/francesworley/.rvm/gems/ruby-2.3.0/bundler/gems/dry-types-861c0b2619a2/lib/dry/types/hash/schema.rb:13:in `each'
     # /Users/francesworley/.rvm/gems/ruby-2.3.0/bundler/gems/dry-types-861c0b2619a2/lib/dry/types/hash/schema.rb:13:in `each_with_object'
     # /Users/francesworley/.rvm/gems/ruby-2.3.0/bundler/gems/dry-types-861c0b2619a2/lib/dry/types/hash/schema.rb:13:in `call'
     # ./lib/dry/validation/schema.rb:203:in `call'
     # ./spec/support/predicates_integration.rb:5:in `result'
     # ./spec/integration/schema/predicates/array_spec.rb:217:in `block (6 levels) in <top (required)>'

  2) Predicates: Array as macro with required when using an input_processor with blank input is not successful
     Failure/Error: processed_input = input_processor[input]

     NoMethodError:
       undefined method `map' for "":String
       Did you mean?  tap
     # /Users/francesworley/.rvm/gems/ruby-2.3.0/bundler/gems/dry-types-861c0b2619a2/lib/dry/types/array/member.rb:13:in `call'
     # /Users/francesworley/.rvm/gems/ruby-2.3.0/bundler/gems/dry-types-861c0b2619a2/lib/dry/types/hash/schema.rb:15:in `block in call'
     # /Users/francesworley/.rvm/gems/ruby-2.3.0/bundler/gems/dry-types-861c0b2619a2/lib/dry/types/hash/schema.rb:13:in `each'
     # /Users/francesworley/.rvm/gems/ruby-2.3.0/bundler/gems/dry-types-861c0b2619a2/lib/dry/types/hash/schema.rb:13:in `each_with_object'
     # /Users/francesworley/.rvm/gems/ruby-2.3.0/bundler/gems/dry-types-861c0b2619a2/lib/dry/types/hash/schema.rb:13:in `call'
     # ./lib/dry/validation/schema.rb:203:in `call'
     # ./spec/support/predicates_integration.rb:5:in `result'
     # ./spec/integration/schema/predicates/array_spec.rb:225:in `block (6 levels) in <top (required)>'
Fran Worley
@fran-worley
Jun 15 2016 11:05
and I'm using the latest dry-logic/types:
Using dry-logic 0.2.3 from git://github.com/dry-rb/dry-logic.git (at master@8f8dffb)
Using dry-types 0.7.2 from git://github.com/dry-rb/dry-types.git (at master@861c0b2)
Piotr Solnica
@solnic
Jun 15 2016 11:07
@fran-worley impossibru
ooops my bad, forgot to push dry-v commit :laughing:
Fran Worley
@fran-worley
Jun 15 2016 11:08
:)
Piotr Solnica
@solnic
Jun 15 2016 11:08
sorry about that
Fran Worley
@fran-worley
Jun 15 2016 11:09
Thats better ! Just adding a spec so we can close dry-rb/dry-validation#114
Piotr Solnica
@solnic
Jun 15 2016 11:14
@fran-worley sweeeeet
dry-rb/dry-types#93 <= wdyt? /cc @timriley
Tim Riley
@timriley
Jun 15 2016 11:14
click
Fran Worley
@fran-worley
Jun 15 2016 11:15
and dry-rb/dry-validation#137 Do you know why the hint compiler doesn't pick up the input @solnic?
Piotr Solnica
@solnic
Jun 15 2016 11:16
it should pass expected and current now because we automatically grab args from predicates
obviously should be verified with a spec so that we know it can be closed
I removed most of the custom options_for_* methods because they were not needed anymore
Fran Worley
@fran-worley
Jun 15 2016 11:17
Yeah and it does, but if I do:
        def self.messages
          Dry::Validation::Messages.default.merge(
            en: { errors: { with_lots_of_args?: '%{foo} %{bar} %{baz} %{value}' } }
          )
        end


        def with_lots_of_args?(foo, bar, baz, input)
          false
        end
I get:
Failure/Error:
       expect(schema.(email: 'email').messages).to eql(
         email: ['foo bar baz email']
       )

       expected: {:email=>["foo bar baz email"]}
            got: {:email=>["foo bar baz email", "foo bar baz "]}

       (compared using eql?)

       Diff:
       @@ -1,2 +1,2 @@
       -:email => ["foo bar baz email"],
       +:email => ["foo bar baz email", "foo bar baz "],

     # ./spec/integration/custom_predicates_spec.rb:148:in `block (2 levels) in <top (required)>'
Piotr Solnica
@solnic
Jun 15 2016 11:19
ah shit, the second one is a hint
Fran Worley
@fran-worley
Jun 15 2016 11:19
Yeah I know, it seems to ignore the input value and then because they aren't the same we get them both
Piotr Solnica
@solnic
Jun 15 2016 11:19
hints don’t have access to input value
so we get two msgs in such cases :(
I gotta improve hint-related stuff
Fran Worley
@fran-worley
Jun 15 2016 11:20
Ok I'll raise that as a different issue :)
Piotr Solnica
@solnic
Jun 15 2016 11:20
ok
Maciej Mensfeld
@mensfeld
Jun 15 2016 11:21
@solnic are you planning to visit http://grillrb.com/ ? ;)
Tim Riley
@timriley
Jun 15 2016 11:21
@solnic I think the odd thing about that bug report is that providing a .constructor on Strict::String overrides the existing constructor applying the strictness semantics. So I don’t actually see any reason why someone would want to actually make a custom type on top of Strict::String, in this case.
Piotr Solnica
@solnic
Jun 15 2016 11:22
@mensfeld no :( I’m in Lviv on these days
Maciej Mensfeld
@mensfeld
Jun 15 2016 11:22
ah what a bummer
Piotr Solnica
@solnic
Jun 15 2016 11:22
I know, I’d love to go
@timriley yeah that’s my thinking too, but maybe it’s not intuitive
Maciej Mensfeld
@mensfeld
Jun 15 2016 11:23
next time then ;)
maybe on KRUG one day
Fran Worley
@fran-worley
Jun 15 2016 11:24
@solnic now that we have the new ast, could we get around this by just using the predicate args as tokens and not injecting 'value' at all?
Piotr Solnica
@solnic
Jun 15 2016 11:24
@mensfeld yep defo need to go to KRUG
@fran-worley yeah we should do that but I’m not entirely sure if we get value in all cases yet
Tim Riley
@timriley
Jun 15 2016 11:24
@solnic I think the “intuitive” thing to happen there would be that existing constructor(s) run first, and the custom-supplied constructor runs on the final output of those existing constructor(s)
Maciej Mensfeld
@mensfeld
Jun 15 2016 11:25
@solnic after the summer break we might figure out a way to bring you in if you would be interested :)
Piotr Solnica
@solnic
Jun 15 2016 11:25
@mensfeld sounds good although I’m gonna be away in September
Tim Riley
@timriley
Jun 15 2016 11:25
@solnic And I think, if we can’t support that - or don’t want to - then perhaps we shouldn’t offer #constructor on top of existing types like that? It should be a “build it yourself from scratch” thing instead.
Maciej Mensfeld
@mensfeld
Jun 15 2016 11:25
@solnic KRUG is back after summer break in October ;) so we have plenty of time
Piotr Solnica
@solnic
Jun 15 2016 11:26
@timriley yeah feels like the api should be narrowed down a bit
Maciej Mensfeld
@mensfeld
Jun 15 2016 11:26
I will make sure to arrange osmething :)
Piotr Solnica
@solnic
Jun 15 2016 11:26
@mensfeld aah that’s perfect then
yeah count me in
Fran Worley
@fran-worley
Jun 15 2016 11:26
@solnic with the new ast, you would do though it would be called whatever you named the arg in your predicate. the only case you wouldn't is if you had no args but then you shouldn't be trying to find it in your message
shall I try it and see?
Tim Riley
@timriley
Jun 15 2016 11:26
@solnic I agree. I think contracting the API a little as a first step makes sense. Then we could expand it to offer behaviours like I described later on.
Piotr Solnica
@solnic
Jun 15 2016 11:27
@fran-worley it’d be AWESOME if we could get rid of ErrorCompiler::Input
it’s being created every time we generate a message, slows stuff down a lot
BUT be aware that handling each errors with messages for specific elements is tricky
Fran Worley
@fran-worley
Jun 15 2016 11:28
Well can you decide what you want to do about tokens? how do we enable '%{list.join}' in the yaml ?
Piotr Solnica
@solnic
Jun 15 2016 11:28
so assuming each results have predicates with proper info in the args…then we’re good
Fran Worley
@fran-worley
Jun 15 2016 11:28
I think my specs in dry-logic were coming out correctly but I'll see what blows up :)
Piotr Solnica
@solnic
Jun 15 2016 11:29
oh right this is covered in dry-logic specs…so theoretically it should just work™ (famous last words)
re list we could introduce some conventions, ie an arg named list would be transformed with list.join(‘, ‘)
we could define arg transformation procs and map them to specific arg names or sutin
Fran Worley
@fran-worley
Jun 15 2016 11:31
doesn't that cause issues with thigs like def some_validate?(list1, list2) ... end etc
Piotr Solnica
@solnic
Jun 15 2016 11:31
@timriley so you think Constrained#constructor should raise an error that this makes no sense?
Fran Worley
@fran-worley
Jun 15 2016 11:31
I assume that introducing something like mustache is a bit overkill...
Piotr Solnica
@solnic
Jun 15 2016 11:31
uhm yeah
why would that cause issues? it’d be a simple name-based convention ie “if you want your message to include a list of things, call predicate arg “list”`
Fran Worley
@fran-worley
Jun 15 2016 11:32
but what if you had a couple of lists as args?
Piotr Solnica
@solnic
Jun 15 2016 11:32
do we have a case like that?
Fran Worley
@fran-worley
Jun 15 2016 11:32
I don't but we support custom predicates and it's not unreasonable that someone mmight
Piotr Solnica
@solnic
Jun 15 2016 11:33
welllll we can match on the type and have a type-based convention
if an arg is an array then it’ll be join-ed
Fran Worley
@fran-worley
Jun 15 2016 11:34
That is probably a better idea.
Piotr Solnica
@solnic
Jun 15 2016 11:35
are you going to try to remove ErrorCompiler::Input?
Fran Worley
@fran-worley
Jun 15 2016 11:36
not sure I can get rid of the whole thing at this point, but certainly remove all the options_for stuff
Tim Riley
@timriley
Jun 15 2016 11:39
@solnic Yeah, I think so (was just looking over the code). For Constrained types it’s important that their original #call is run, and not overridden by someone else’s constructor, because otherwise we’re losing their constraints.
That is, I think this is what would be a reasonable step to prevent misunderstandings, until perhaps we could consider a more sophisticated “layering” of constructors later on.
Piotr Solnica
@solnic
Jun 15 2016 11:40
it is layered already :)
it’s just that the person who reported that issue thought it would apply constraints before his constructor
so basically he thought it would check if the input is valid for his constructor
but it doesn’t work like that, constructors are called in reversed order of definition
so last is called first
Tim Riley
@timriley
Jun 15 2016 11:43
Ah, right.
Yeah, I get this now.
WONTFIX?
“Write your constructor better?"
I think it’s a not unreasonable expectation for constrained types to check their own constraints first, though.
Piotr Solnica
@solnic
Jun 15 2016 11:46
welll constructor is defined ON TOP of an existing type
Tim Riley
@timriley
Jun 15 2016 11:46
and therefore run first
yeah
that makes sense
it’s the outermost layer
Piotr Solnica
@solnic
Jun 15 2016 11:51
a constructor can transform invalid input to valid, hence it’s on top
ie stripping a string may make a string valid according to size constraint
stuff like that…
Tim Riley
@timriley
Jun 15 2016 11:51
Yeah.
Lairan
@alex-lairan
Jun 15 2016 12:14
@fran-worley I've done this:
en:
  errors:
    valid_role?: 'isn\'t a valid role'

How I can bind

configure do
    config.messages_file = '/path/to/errors.yml'
    def valid_role?(value)
        Role.all.map(&:name).include?(value)
    end
end

with the errors.yml? :)

Thank for your help :)
Fran Worley
@fran-worley
Jun 15 2016 12:19
@alex-lairan if that is where your errors file is located then that should 'just work'
Lairan
@alex-lairan
Jun 15 2016 12:21

I got

did not find expected key while parsing a block mapping at line 3 column 5

Fran Worley
@fran-worley
Jun 15 2016 12:24
that would imply that there is something wrong with your yml file
Lairan
@alex-lairan
Jun 15 2016 12:25
This errors.yml is the same on my project
Fran Worley
@fran-worley
Jun 15 2016 12:29
Try copying the default one from the gem and checking that you get the missing message error (that would prove that your picking up your custom messages yml correctly) then try adding your message back in
Lairan
@alex-lairan
Jun 15 2016 12:29
I use this predicate with: key(:name).required(:str?, :valid_role?)
ok I try it :)
Ok one of the problem is \'
Fran Worley
@fran-worley
Jun 15 2016 12:34
just use "isn't"
Lairan
@alex-lairan
Jun 15 2016 12:34
Yes

another problem now :)

ArgumentError: +valid_role?+ is not a valid predicate name

Fran Worley
@fran-worley
Jun 15 2016 12:40
@alex-lairan what version of dry-validation are you using?
Lairan
@alex-lairan
Jun 15 2016 12:52
The 0.7.4 version
Fran Worley
@fran-worley
Jun 15 2016 12:54
With version 0.7.4 you may have to use a block instead of the macro for custom predicates:
key(:name) { filled? & str? & valid_role? }
Lairan
@alex-lairan
Jun 15 2016 12:56
And this is ok?
     configure do
        config.messages_file = '/path/errors.yml'
        def valid_role?(value)
          Role.all.map(&:name).include?(value)
        end
      end
Fran Worley
@fran-worley
Jun 15 2016 12:57
@alex-lairan I can't remember what you have access to inside custom predicates in 0.7.4 but at the very least you should get a different error ...
Ralf Schmitz Bongiolo
@mrbongiolo
Jun 15 2016 13:00
@solnic, @timriley I just read about that issue, and I would expect that Strict::String runs before my own constructor, since I'm using it as a "base" for my type. So this base type basically is there to identify the final valid type, I could have a Strict::String::TrimmedDowncasedAndSnaked but in the end it would just be a String. We might just need some improvements on the docs to explain that the custom constructors will run before the base and it's your responsibility to check the types, if needed.
Piotr Solnica
@solnic
Jun 15 2016 13:01
@mrbongiolo that too, or we can have an API for handling this somehow
Ralf Schmitz Bongiolo
@mrbongiolo
Jun 15 2016 13:02
that's an option too
Lairan
@alex-lairan
Jun 15 2016 13:02
@fran-worley my project look like this:
@schema = Dry::Validation.Schema do
    # Some stuff
    key(:values).schema(values_schema)
    .
    .
    .
end

def values_schema
    Dry::Validation.Schema do
        configure do
      config.messages_file = '/path/to/errors.yml'
      def valid_role?(value)
        Chef::Role.all.map(&:name).include?(value)
      end
    end

    optional(:roles).each do
            schema do
                key(:name) { filled? & str? & valid_role? }
            end
        end
    end
end
Piotr Solnica
@solnic
Jun 15 2016 13:03
@alex-lairan try with i18n IIRC there’s a known bug in plain-yaml messages where custom messages are not being merged correctl with defaults :/
Lairan
@alex-lairan
Jun 15 2016 13:04
Ok I try with this ;)
Piotr Solnica
@solnic
Jun 15 2016 13:05
most people use i18n so plain yaml-based messages didn’t receive much attention
Ralf Schmitz Bongiolo
@mrbongiolo
Jun 15 2016 13:08
@solnic doesn't all dry::types already do type checking? they are meant to be the very smallest case, that's why I thought they would run first, if the input isn't a string I don't even want my constructor to run. And when I have to check type on it, I'll end up sending it down and the type would be checked again, which seems strange...
Piotr Solnica
@solnic
Jun 15 2016 13:10
constructors are meant to receive a potentially invalid input and turn it into valid so…
Ralf Schmitz Bongiolo
@mrbongiolo
Jun 15 2016 13:10
something like this: input.is_a?(::String) ? input.gsub(/\D/, '') : input, if it's a String then get the numbers, if not then send it to strict.string to raise an error...
Piotr Solnica
@solnic
Jun 15 2016 13:11
it really depends on the context and what you’re trying to do, the way it works now makes perfect sense for things we need in dry-v and other places
I’m not against an API that would work like you want though
Lairan
@alex-lairan
Jun 15 2016 13:12

I have another problem ^^

undefined method `merge' for #<Dry::Validation::Messages::I18n:0x00000004d217d0>

My configure:
configure do
        config.messages = :i18n
        config.messages_file = '/home/lairan/Documents/selfdeploy/app/validators/errors.yml'
        def valid_role?(value)
          Chef::Role.all.map(&:name).include?(value)
        end
      end
Ralf Schmitz Bongiolo
@mrbongiolo
Jun 15 2016 13:12
I do understand why they are layered like that now, it's just that as the issue shown, people will expect it to work the other way :D
Piotr Solnica
@solnic
Jun 15 2016 13:12
@alex-lairan pls report an issue
Lairan
@alex-lairan
Jun 15 2016 13:12
Okay I will :)
Piotr Solnica
@solnic
Jun 15 2016 13:13
@mrbongiolo I need to think about this more
Ralf Schmitz Bongiolo
@mrbongiolo
Jun 15 2016 13:14
fine, no problem, I'm just saying because that behavior was a "surprise" to me
Piotr Solnica
@solnic
Jun 15 2016 13:17
fwiw if something is strict then it shouldn’t need a constructor
and remember you can do stuff like this:
irb(main):008:0> Types::Coercible::String.constructor(&:strip).constrained(type: String)[" foo "]
=> "foo"
irb(main):009:0> Types::Coercible::String.constructor(&:strip).constrained(type: String)[1]
=>1
Lairan
@alex-lairan
Jun 15 2016 13:21
require 'dry-validation'

schema = Dry::Validation.Schema do
  configure do
    config.messages_file = './errors.yml'
    def valid_role?(value)
      %w(Admin Viewer Actor).include?(value)
    end
  end

  optional(:roles).each do
    schema do
      key(:name) { filled? & str? & valid_role? }
    end
  end
end

pp schema.call(roles: [{name: 'Admin'}, {name: 'Test'}]).messages
This code fail with this error:
/home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-validation-0.7.4/lib/dry/validation/schema.rb:195:in `[]': +valid_role?+ is not a valid predicate name (ArgumentError)
    from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:54:in `visit_predicate'
    from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:18:in `visit'
    from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:32:in `visit_key'
    from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:18:in `visit'
    from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:59:in `visit_and'
    from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:18:in `visit'
    from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:59:in `visit_and'
    from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:18:in `visit'
    from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-validation-0.7.4/lib/dry/validation/schema.rb:254:in `block in initialize_rules'
    from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-validation-0.7.4/lib/dry/validation/schema.rb:253:in `each'
    from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-validation-0.7.4/lib/dry/validation/schema.rb:253:in `each_with_object'
    from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-validation-0.7.4/lib/dry/validation/schema.rb:253:in `initialize_rules'
    from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-validation-0.7.4/lib/dry/validation/schema.rb:174:in `initialize'
    from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-validation-0.7.4/lib/dry/validation/schema.rb:46:in `new'
    from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-validation-0.7.4/lib/dry/validation/schema.rb:46:in `new'
    from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-validation-0.7.4/lib/dry/validation/schema_compiler.rb:33:in `visit_schema'
    from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:18:in `visit'
    from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:59:in `visit_and'
    from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:18:in `visit'
    from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:13:in `block in call'
    from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:13:in `map'
    from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:13:in `call'
    from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:45:in `visit_set'
    from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:18:in `visit'
    from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:49:in `visit_each'
    from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:18:in `visit'
    from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:59:in `visit_and'
    from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:18:in `visit'
    from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:32:in `visit_key'
    from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:18:in `visit'
    from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:74:in `visit_implication'
    from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:18:in `visit'
    from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-validation-0.7.4/lib/dry/validation/schema.rb:254:in `block in initialize_rules'
    from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-validation-0.7.4/lib/dry/validation/schema.rb:253:in `each'
    from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-validation-0.7.4/lib/dry/validation/schema.rb:253:in `each_wit
I create issue
Piotr Solnica
@solnic
Jun 15 2016 13:25
@alex-lairan oh that’s an interesting use-case, pls report. as a workaround you can define an external schema with the predicate and do schema(RoleSchema)
that configure block defines predicate methods on the main schema, and inside each we create a new one, which doesn’t inherit outer schema predicates hence the error
Ralf Schmitz Bongiolo
@mrbongiolo
Jun 15 2016 13:26
@solnic maybe what we need is some kind of "filters" or "transformers", those would apply after everything else. So the constructor would be used only for complex cases.
ex: my api could accept all these as valid date: "10/02/2016", '2016-02-10', [2016, 10, 02], 02/10/2016 and so on, so the constructor would check all the possibilities and return a Date, after that we could transform that value, if needed. I'm not sure if Dry::Types is aiming for this type of data transformation, but some constructors are used like that.
Piotr Solnica
@solnic
Jun 15 2016 13:30
constrained types are meant to be used for type-checking in places like structs where input is expected to be valid, they are not meant to be used as a sanity check for custom constructors. so we basically need a new concept
let’s postpone this for 0.9.0 though, I’m WAY behind my schedule already
Ralf Schmitz Bongiolo
@mrbongiolo
Jun 15 2016 13:33
@solnic sure, that makes sense