Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Apr 22 18:05
    ytaben commented #72
  • Apr 22 18:05
    ytaben commented #72
  • Apr 22 18:04
    ytaben commented #72
  • Apr 22 14:16
    ytaben synchronize #72
  • Apr 22 14:04
    ytaben synchronize #72
  • Apr 22 12:55

    timriley on master

    Bump dry-system to 0.19.0 (compare)

  • Apr 22 12:55

    timriley on v0.19.0

    Bump dry-system to 0.19.0 (compare)

  • Apr 22 12:49

    dry-bot on master

    [devtools] sync (compare)

  • Apr 22 12:48

    timriley on master

    Update changelog (compare)

  • Apr 22 12:48

    dry-bot on master

    [devtools] sync (compare)

  • Apr 22 12:47

    timriley on master

    Update changelog (compare)

  • Apr 22 06:26
    solnic review_requested #72
  • Apr 22 06:26
    solnic commented #72
  • Apr 22 01:57

    dry-bot on master

    [devtools] sync (compare)

  • Apr 22 01:57

    timriley on master

    Fix changelog (compare)

  • Apr 22 01:34

    dry-bot on master

    [devtools] sync (compare)

  • Apr 22 01:34

    timriley on master

    Add changelog entry for 0.19.0 … (compare)

  • Apr 22 01:34

    timriley on add-0-19-0-changelog

    (compare)

  • Apr 22 01:34
    timriley closed #161
  • Apr 22 01:27
    samkcarlile starred dry-rb/dry-monads
Piotr Solnica
@solnic
it is
Andy Holland
@AMHOL
I guess we could validate the structure of the input too
Piotr Solnica
@solnic
I definitely do not want to make too many assumptions
yeah me too
Andy Holland
@AMHOL
Don't know whether that adds any value though
Piotr Solnica
@solnic
it does, there are cases where you really do want to validate the structure, not just values
ie in my current project at work it is the requirement
Andy Holland
@AMHOL
Fair enough, makes sense to do that then
Piotr Solnica
@solnic
ie {} is not the same as { email: nil } even though {}[:email] happily returns nil
but that’s just our wonderful ruby world :joy:
Andy Holland
@AMHOL
I guess if you validate, then send the data straight to the database, writing key-value pairs, it would make sense to validate the structure
Yeah :joy:
Piotr Solnica
@solnic
ok, I’ll figure something out
the data type we build is a hash with explicit schema (from dry-data)
it ignores unknown keys and handles only the ones you specified
so it’s gonna coerce what is needed
then it’s on the validation side to do what’s appropriate :)
Andy Holland
@AMHOL
Cool
@AMHOL there we go ^
Andy Holland
@AMHOL
Nice, so that's separate for when you want coercion too?
Piotr Solnica
@solnic
yes
it still blindly symbolizes all keys, gotta work on that part now
maybe it’s not a bad idea to add key coercion to dry-data hash
Andy Holland
@AMHOL
Explicitly?
Piotr Solnica
@solnic
yes
Andy Holland
@AMHOL
Can't think of any reason not to
Piotr Solnica
@solnic
heh adding support for passing a block to predicates in the dsl was too easy, it’s a very good sign #happypanda
to make the dsl more concise I’m considering this now:
key(:address).hash? do |address|
  address.key(:age).int? { |value| value.gt?(18) }
end
@AMHOL WDYT? ^
Piotr Solnica
@solnic
this would be less trivial to implement though :)
Andy Holland
@AMHOL
As opposed to:
key(:address).hash? do |address|
  address.key(:age).int? & address.key(:age).gt?(18)
end
?
Piotr Solnica
@solnic
not exactly
type check is kind-of special
first of all you specify the expection for the type so we can infer coercion logic from it
secondly it’s the very first check that needs to be done before we can do anything else with the value
Andy Holland
@AMHOL
Ahh OK
Piotr Solnica
@solnic
so having it outside of the block would make sense
I dunno, will see, not gonna do that now, just wondering
Andy Holland
@AMHOL
So the predicate would be a pre-requisite to the validations running inside of the block?
Piotr Solnica
@solnic
yes
Andy Holland
@AMHOL
That makes sense :+1:
Piotr Solnica
@solnic
I just added support for passing blocks to predicate checks, which does the very same thing, but for type-check you get one more level of nesting
hence my thought about moving it to the outer block
Andy Holland
@AMHOL
Yep, that works for me
Piotr Solnica
@solnic
you can do value.int? & value.gt?(18) and the equivalent of this is using a block like this; value.int? { value.gt?(18) }
in general a block == AND
Andy Holland
@AMHOL
So it's like a normal AND where the right only evaluates if the left passes?