These are chat archives for dry-rb/chat

7th
Jun 2016
Andy Holland
@AMHOL
Jun 07 2016 00:50
:D
Chase Gilliam
@Ch4s3
Jun 07 2016 03:54
:clap:
John Backus
@backus
Jun 07 2016 04:20
@solnic if you agree with dry-rb/dry-validation#179 I would be interested in implementing it
Would be easier to implement this if attr hadn't been nixed entirely
Oskar Szrajer
@gotar
Jun 07 2016 06:02
@timriley I change code to reflect your proposals, all works - thx
Tim Riley
@timriley
Jun 07 2016 06:07
@gotar super! :D
Fran Worley
@fran-worley
Jun 07 2016 08:22
@solnic should I merge dry-rb/dry-validation#178 ?
Piotr Solnica
@solnic
Jun 07 2016 09:05
@fran-worley oh fantastic <3 could you add a more descriptive message when merging?
Fran Worley
@fran-worley
Jun 07 2016 09:07
Yeah sorry I forgot to change it before I pushed it!
Piotr Solnica
@solnic
Jun 07 2016 09:13
no worries :)
it just helps when compiling a changelog as we all keep forgetting about keeping it up-to-date :laughing:
@fran-worley I’m gonna take care of dis: dry-rb/dry-validation#165
Fran Worley
@fran-worley
Jun 07 2016 09:50
Thanks, I got really stuck :cry: I've updated the changelog dry-rb/dry-validation@a99c644
Piotr Solnica
@solnic
Jun 07 2016 09:54
@fran-worley no worries, we’ll figure this out :)
thanks for the changelog update <3
@AMHOL heeyyyyy is dry-container supposed to work with objects too?
Fran Worley
@fran-worley
Jun 07 2016 09:57
@solnic cool. Happy to have another look at dry-rb/dry-logic#13 when you've sorted dry-rb/dry-validation#165.
Piotr Solnica
@solnic
Jun 07 2016 10:56
dry-rb/dry-validation#180 /cc @fran-worley
now I gotta make that registry available in the DSL so we can actually verify if a given predicate is valid
and the last step will be to figure out how to recompile rules and automatically bind predicates to a new instance of a schema w/o recompiling everything
Fran Worley
@fran-worley
Jun 07 2016 10:58
:smirk: now I remember why I left this until you got back @solnic !
Piotr Solnica
@solnic
Jun 07 2016 10:58
hah!
Piotr Solnica
@solnic
Jun 07 2016 11:50
@fran-worley ok this is ready (except recompilation improvement, but that can wait)
check dis out:
(byebug) klass = Class.new(Dry::Validation::Schema)
(byebug) klass.registry[:min_size?]
#<Dry::Logic::Predicate id=:min_size? args=[]>
(byebug) klass.registry[:min_size?].fn.parameters
[[:opt, :num], [:opt, :input]]
Fran Worley
@fran-worley
Jun 07 2016 11:51
Amazing :smile:
Piotr Solnica
@solnic
Jun 07 2016 11:51
and this is now available in the DSL objects via registry object that’s passed to the dsl
I added validation of predicate definitions too, checking names and arity for a good start
we gotta add #arity and #parameters to Dry::Logic::Predicate too
they should quack like procs/method-objects
Fran Worley
@fran-worley
Jun 07 2016 11:53
yup. In theory then is there much point in changing the AST at all ?
Piotr Solnica
@solnic
Jun 07 2016 11:54
yeah would be good if we could avoid changing ast
could you remind why…we needed that? :D
I kinda lost the context :)
Fran Worley
@fran-worley
Jun 07 2016 11:55
1) to get the param names in dry-v (which you've solved) and 2) to make the ast more readable (maybe not an issue?)
Piotr Solnica
@solnic
Jun 07 2016 11:55
ok but we needed param names in order to…?
Fran Worley
@fran-worley
Jun 07 2016 11:56
improve messages so that custom predicates can access more than just 'value'
Piotr Solnica
@solnic
Jun 07 2016 11:57
oh rrrright, well error compilers use AST, not rule objects
Fran Worley
@fran-worley
Jun 07 2016 11:57
and therefore enable us to start removing manual options_for_#{predicate} definitions
Piotr Solnica
@solnic
Jun 07 2016 11:57
that would be a huge improvement…right right now I remember
why did you have to change the way result stuff is working in dry-logic?
I’d like to avoid that tbf
Fran Worley
@fran-worley
Jun 07 2016 11:59
Yeah I didn't like it either but without it the input param was getting cached and when using each I was just getting the same result
Piotr Solnica
@solnic
Jun 07 2016 12:00
it should be possible to extend rule ast with param info now that we have that in the DSL
oh wait, that should not be needed, rules can dump themselves to an ast format with the info we need
error compilers use result ast which includes info about rules that failed so that should be everything

the input param was getting cached and when using each I was just getting the same result

^ could you point me to source code where that happens?

Fran Worley
@fran-worley
Jun 07 2016 12:08

@solnic it's not in your code, but the rather messy attempt I made at matching param names with values:
https://github.com/dry-rb/dry-logic/pull/13/files#diff-987214a96aa6330f9fb42439cbfe2584R44

I had been trying to treat input (and other call params) just like any other param, so when you define the predicate the ast shows the param with a nil value and the result merges call params with empty hash params.

I'll have another look as I think we can easily simplify this right down :smile:
Piotr Solnica
@solnic
Jun 07 2016 12:08
yeah I would really expect this to be simple to do now
we’ve got all the info we need
in fact, I could tweak PredicateRegistry to build Predicate objects even for unbound methods, so that the DSL can simply call to_ast on them instead of building that manually, that would decrease the coupling too, so win-win
Fran Worley
@fran-worley
Jun 07 2016 12:11
Lovely. I think we agreed that a predicates ast changes from:
#current
[:predicate, [:eql?, [12]]

#new (after curry but before call)
[:predicate, [:eql?, [[:left, 12], [:right, nil]]]

#new (after call)
[:predicate, [:eql?, [[:left, 12], [:right, 11]]]
Piotr Solnica
@solnic
Jun 07 2016 12:21
ah ok so we need to provide info about params and their values and use nil for the actual input
I gotta think about this :)
Fran Worley
@fran-worley
Jun 07 2016 12:23
yeah, I think that the overall result ast still needs (input) as it's not always the same as for a single predicate (e.g. in arrays etc.) plus that really separates predicates from being validation specific
e.g.
require 'dry/logic/rule'

RSpec.describe Dry::Logic::Rule::Each do
  include_context 'predicates'

  subject(:address_rule) do
    Dry::Logic::Rule::Each.new(is_string)
  end

  let(:is_string) { Dry::Logic::Rule::Value.new(str?) }

  describe '#call' do
    it 'applies its rules to all elements in the input' do
      expect(address_rule.(['Address'])).to be_success

      expect(address_rule.([nil, 'Address'])).to be_failure
      expect(address_rule.([:Address, 'Address'])).to be_failure
    end

    it 'returns result ast' do
      expect(address_rule.([1, nil]).to_ast).to eql([
        :result, [[1, nil], [
          :each, [
            [:el, [0, [:result, [1, [:val, [:predicate, [:str?, [[:input, 1]]]]]]]]],
            [:el, [1, [:result, [nil, [:val, [:predicate, [:str?, [[:input, nil]]]]]]]]]
          ]
        ]]
      ])
    end
  end
end
Piotr Solnica
@solnic
Jun 07 2016 12:34
OK thanks @fran-worley - I’m gonna look into that tomorrow or today late evening
Fran Worley
@fran-worley
Jun 07 2016 12:36
This message was deleted
Andy Holland
@AMHOL
Jun 07 2016 12:44
@solnic WDYM?
Piotr Solnica
@solnic
Jun 07 2016 12:45
nevermind ;)
Piotr Solnica
@solnic
Jun 07 2016 12:51
@backus yeah that would be a great new feature but let’s hold off a bit until I finish dry-rb/dry-validation#180
Piotr Solnica
@solnic
Jun 07 2016 13:32
dry-rb/dry-validation#181 <== need some feedback on dis /c @timriley @AMHOL @jodosha @fran-worley @backus
Andy Holland
@AMHOL
Jun 07 2016 13:40
@solnic defo :+1: for moving towards a more explicit approach, would definitely add a deprecation warning, also need to keep in mind 2 step validations (i.e a schema step for type coercion/validation then a step for domain validation, which could be a deal breaker if that complicates things?)
Piotr Solnica
@solnic
Jun 07 2016 13:41
it doesn’t complicated things
it’s really a matter of treating type expectations explicitly and turning this into a requirement and a correct usage of the library
Andy Holland
@AMHOL
Jun 07 2016 13:42
:+1:
Piotr Solnica
@solnic
Jun 07 2016 13:42
not to mention that we could remove input processor compilers completely…
if we go with deprecations that part would have to wait for 0.9.0 or 1.0.0
Andy Holland
@AMHOL
Jun 07 2016 13:45
Think that's fair enough, gives people time to switch over and makes it easier to do so?
Piotr Solnica
@solnic
Jun 07 2016 13:45
yep
I hope this will make it easier to implement chaining so that we can have required(:tags).type(:array?).value(size?: 1..10).each(:int?)
anyhow, it’d be awesome if anybody could help with this dry-rb/dry-rb.org#59
Fran Worley
@fran-worley
Jun 07 2016 14:01
@solnic any thoughts on how to store the call args for a predicate to enable us to return the full AST without creating a new object?
That is why I ended up with Predicate::Result, but I appreciate it's a bit overkill just to capture the args.
Piotr Solnica
@solnic
Jun 07 2016 14:57
@fran-worley result objects have access to all args
Fran Worley
@fran-worley
Jun 07 2016 15:20
@solnic thanks so we are ok with the fact that predicate.to_ast will only ever return curried args?
Piotr Solnica
@solnic
Jun 07 2016 15:21
yeah I think this should be enough, we can grab the actual input from result ast
error compiler has this Input object which has access to input value
Fran Worley
@fran-worley
Jun 07 2016 15:22
but in dry-logic result ast calls rule ast which calls predicate ast. We could just inject call args into the predicate ast method?
Piotr Solnica
@solnic
Jun 07 2016 15:54
that’s an option too
Fran Worley
@fran-worley
Jun 07 2016 15:57
I just figured that we should make this change work independently of dry-validation
result.to_ast in dry-logic should be able to return the full predicate ast
Piotr Solnica
@solnic
Jun 07 2016 15:58
that would be good yeah
I’m not 100% happy with how result stuff works anyway so it’s a good moment to think about improving it
Fran Worley
@fran-worley
Jun 07 2016 16:01
@solnic dry-rb/dry-logic@9a6d975 works for all but check rules, however I'm not sure that I like to_ast accepting a param....
Piotr Solnica
@solnic
Jun 07 2016 16:02
hm yeah…I mean…this isn’t really an actual ast representation of a predicate, so it does feel weird
Fran Worley
@fran-worley
Jun 07 2016 16:03
its the ast of the predicate result
Piotr Solnica
@solnic
Jun 07 2016 16:03
that’s why I separated results
yeah exactly
Fran Worley
@fran-worley
Jun 07 2016 16:03
Which is why last time I ended up with Predicate::Result...
Piotr Solnica
@solnic
Jun 07 2016 16:05
I need to understand why that was needed first :) I’ll be digging into that tomorrow
Fran Worley
@fran-worley
Jun 07 2016 16:06
Ok, shall I just leave it for now?
I have one more idea that might be better :smile:
Piotr Solnica
@solnic
Jun 07 2016 16:27
@fran-worley no I’m just saying I still don’t have a full understanding of the problems you’re facing so in order to provide better feedback I need to dig into this and I’m busy working atm :)
so pls feel free to experiment with this if you find this to be sth interesting :)
Fran Worley
@fran-worley
Jun 07 2016 16:28
Ah ok. Sorry I've got rather attached to this. It will not defeat me!
Piotr Solnica
@solnic
Jun 07 2016 16:28
hah awesome :muscle:
Luca Guidi
@jodosha
Jun 07 2016 17:09
Hey folks, I was sick over the weekend. I'm trying to catchup with all the conversations. /cc @solnic
Piotr Solnica
@solnic
Jun 07 2016 17:17
@jodosha oh sorry to hear that
Luca Guidi
@jodosha
Jun 07 2016 17:18
@solnic Thanks, I'm fine now :)
Fran Worley
@fran-worley
Jun 07 2016 18:15
@sonic is this allowed? https://github.com/dry-rb/dry-logic/blob/master/spec/unit/rule/value_spec.rb#L22
Surely a predicate should be an instance of Predicate and not just a random function ?
Piotr Solnica
@solnic
Jun 07 2016 18:20
@fran-worley we rely on the interface, in fact, dry-v schema implements it
Fran Worley
@fran-worley
Jun 07 2016 18:21
so how do you call to_ast without the function being wrapped in a predicate class?
Piotr Solnica
@solnic
Jun 07 2016 18:21
to_ast is a required interface
Fran Worley
@fran-worley
Jun 07 2016 18:23
Oh ok cool. Just checking thanks,
Nikita Shilnikov
@flash-gordon
Jun 07 2016 20:06
@ttdonovan re crystal, sorry for this late response, I've just seen the tab with your repo. I don't think we have any plans about dry-cr or sutin right now. Feel free to have your own implementation or to make a proposal to ruby version if you have any. Personally I don't know Crystal and I don't think I will in the near future, I'm reading about elixir/phoenix atm and Haskell is on my list (which I guess will take a looot of time :) ) And OCaml or refreshing Scala further, dunno :)
Piotr Solnica
@solnic
Jun 07 2016 20:07
my gut feeling is tellin me it’s gonna be hard to port dry stuff to crystal
we use a bunch of advanced meta-programming techniques from ruby
ie module subclassing, juggling method objects etc.
Joe Van Dyk
@joevandyk
Jun 07 2016 21:24
any reason https://github.com/dry-rb/dry-result_matcher hasn’t been released?
@timriley ^
Piotr Solnica
@solnic
Jun 07 2016 21:41
Joe Van Dyk
@joevandyk
Jun 07 2016 21:42
@solnic the release of using dry-monad i mean
(i suppose and updating docs)
Piotr Solnica
@solnic
Jun 07 2016 21:42
oh I see :)
I bet it’s just because nobody had the time to do so
Tim should be here soon so he should be able to clarify
Tim Riley
@timriley
Jun 07 2016 21:55
@joevandyk I reckon I can release that this morning :) I've just been working through a backlog of gem updates. Thanks for the reminder!
Tim Riley
@timriley
Jun 07 2016 22:00
Also, 👋🏼 everyone.
Piotr Solnica
@solnic
Jun 07 2016 22:03
:wave:
AU shift starts PL goes to sleep :laughing:
Fran Worley
@fran-worley
Jun 07 2016 22:05
Hey @timriley :waxing_crescent_moon:
Tim Riley
@timriley
Jun 07 2016 22:06
dry-rb is here for you always
nicholas a. evans
@nevans
Jun 07 2016 22:14
I'm just getting started with dry-types (moving over from Virtus; thanks!); Q: under what circumstances would I ever not want to use a strict or coerced type? e.g. are Types::Time, Types::String, Types::Int meant to be used as anything other than building blocks for the actually useful types (strict, coerced, etc)?
Piotr Solnica
@solnic
Jun 07 2016 22:17
@nevans whenever you just need a type annotation that other stuff might depend on
ie in rom-rb we use such definitions for relation schemas
nicholas a. evans
@nevans
Jun 07 2016 22:17
metadata then?
Piotr Solnica
@solnic
Jun 07 2016 22:17
pretty much
in fact, there’s an API for adding arbitrary info to types called, wait for it, #meta!
nicholas a. evans
@nevans
Jun 07 2016 22:18
I suppose you could use that to generate e.g. strict and form-coerced versions of a single struct type?
Piotr Solnica
@solnic
Jun 07 2016 22:18
so ie we can have stuff like Types::Int.meta(primary_key: true)
yeah, coercions and constraints are basically wrappers around basic definitions. so ie a type that can coerce an input has a definition and a constructor function that can do whatever you want
Piotr Solnica
@solnic
Jun 07 2016 22:20
and a strict type is a constrained type that which applies a type-check rule when processing an input
nicholas a. evans
@nevans
Jun 07 2016 22:20
thanks!
Piotr Solnica
@solnic
Jun 07 2016 22:22
pls keep in mind that dry-types doesn’t really translate directly from virtus, so ie we don’t have mutable structs and the attribute API is completely different as the behavior is defined by types, not attribute options
this makes them super reusable
nicholas a. evans
@nevans
Jun 07 2016 22:29
oh, I hadn't noticed that structs were immutable! That actually makes me smile... although it'll mean more work in transitioning from virtus, since many of my existing virtus objects are mutated.
Piotr Solnica
@solnic
Jun 07 2016 22:32
@nevans welllllll we’re not freezing them, so you can add attr_writers and since you have access to hash schemas from a struct (as simple as self.class.schema) then it’s easy to implement
by attr writers I meant actual custom foo= methods that use self.class.schema[:foo] to process the value
nicholas a. evans
@nevans
Jun 07 2016 22:33
yeah, seems like it wouldn't be very much work to create a (limited and with caveats) mutable version of Struct for convenience (although I understand discouraging its usage, not wanting to put it in the base library).
Piotr Solnica
@solnic
Jun 07 2016 22:33
right, it’s not gonna be supported by the lib
I bet ~80% of virtus usage can be trivially replaced by dry-types structs + a custom extension for writing attrs
nicholas a. evans
@nevans
Jun 07 2016 22:34
fortunately, most of my virtus usage was already Virtus.value_object:)
Piotr Solnica
@solnic
Jun 07 2016 22:35
that’s good :)
syntax is nicer in dry-types, just inherit from Dry::Types::Value and define attributes as always
values are being frozen btw
but not deeply
nicholas a. evans
@nevans
Jun 07 2016 22:36
:+1:
Fran Worley
@fran-worley
Jun 07 2016 22:38
This message was deleted
With that, I think our dry-monads transition is complete!
Piotr Solnica
@solnic
Jun 07 2016 22:40
:tada: :tada: :tada: :tada: :tada: :tada:
Tim Riley
@timriley
Jun 07 2016 22:40
Feels Right()
Piotr Solnica
@solnic
Jun 07 2016 22:40
I see what you did there
Tim Riley
@timriley
Jun 07 2016 22:41
No pun Left() unturned
Piotr Solnica
@solnic
Jun 07 2016 22:41
oh you’re getting good at this
Tim Riley
@timriley
Jun 07 2016 22:42
:smirk:
Piotr Solnica
@solnic
Jun 07 2016 22:42
I see some potential for really cool slides, it will Maybe(work)
you just gotta Try and see
Tim Riley
@timriley
Jun 07 2016 22:43
hehehee
Nikita Shilnikov
@flash-gordon
Jun 07 2016 22:58
:laughing: :+1: