These are chat archives for dry-rb/chat

2nd
Apr 2016
John Backus
@backus
Apr 02 2016 00:27 UTC
Regarding @dgollahon's inheritance question from earlier it looks like the child behaves as expected if you give it another attribute
require 'dry-types'

module Types
  include Dry::Types.module
end

class Foo < Dry::Types::Struct
  attribute :thing, Types::Strict::String
end

Foo.new(thing: 'hello, world!') #  => #<Foo thing="hello, world!">
Foo.new({}) # !> [Foo.new] :thing is missing in Hash input (Dry::Types::StructError)

class Bar < Foo
end

hmm = Bar.new(thing: 'hello, world!') #  => #<Bar>
hmm.thing # => "hello, world!" # !> method redefined; discarding old meta
# seems ok

wait_wat = Bar.new({}) # => #<Bar>
wait_wat.thing # => nil
# huh? ^

class Baz < Foo
  attribute :other_thing, Types::Strict::String
end

Baz.new(thing: 'hello world', other_thing: 'hi world') # => #<Baz thing="hello world" other_thing="hi world">
Baz.new({}) # !> [Baz.new] :thing is missing in Hash input (Dry::Types::StructError)
You can also hack around this by just invoking the attributes singleton method:
class Hack < Foo
  attributes({})
end

Hack.new(thing: 'hello') # => #<Hack thing="hello">
Hack.new({}) # !> [Hack.new] :thing is missing in Hash input (Dry::Types::StructError)
John Backus
@backus
Apr 02 2016 00:33 UTC
This seems like a bug. @solnic I can open an issue if you would like
Nick Sutterer
@apotonick
Apr 02 2016 07:01 UTC
can anyone point me to how Virtus::Attribute is replaced with dry-types? i'm working on reform 2.2 and want to get rid of all virtus
Nick Sutterer
@apotonick
Apr 02 2016 07:11 UTC
i found it out myself, and love it. an "attribute" is simply a callable object now <3
Tim Cooper
@coop
Apr 02 2016 11:25 UTC

dry-rb/dry-validation#90 <== any thoughts?

I’m still composing my thought on this but required/optional instead of key/optional for key validation seems like a really big improvement. I’m not sold on the value side at the moment.

Tim Cooper
@coop
Apr 02 2016 11:52 UTC
FWIW ^^^
Piotr Solnica
@solnic
Apr 02 2016 11:53 UTC
@coop yeah, in fact, that’s what I wanted to do before 0.7, but for some reason I didn't
Tim Cooper
@coop
Apr 02 2016 11:54 UTC
I’m not convinced not_nil is correct for the value side but I understand what the author is trying to say.
Piotr Solnica
@solnic
Apr 02 2016 11:54 UTC
yeah, we realized it’s a deeper issue
apart from the DSL-side of things
because we use filled? predicate, which is kind of ambigious
Tim Cooper
@coop
Apr 02 2016 11:55 UTC
To be honest I found it really challenging when originally submitting PRs.
I still do but I kind of understand what is going on.
Piotr Solnica
@solnic
Apr 02 2016 11:56 UTC
yeah, in reality both left-side and right-side methods are macros
key is a macro which generates key?(name) rule
then it ANDs it with whatever the right side generates
Tim Cooper
@coop
Apr 02 2016 11:56 UTC
Yep and I understand why you chose key as a macro.
Piotr Solnica
@solnic
Apr 02 2016 11:57 UTC
yeah it’d be a boilerplate horror otherwise
Tim Cooper
@coop
Apr 02 2016 11:57 UTC
I do think required and optional would read better on the key side.
Piotr Solnica
@solnic
Apr 02 2016 11:57 UTC
same with required and maybe as the cover an extremely common case
Tim Cooper
@coop
Apr 02 2016 11:57 UTC
The value side is tricky.
Piotr Solnica
@solnic
Apr 02 2016 11:57 UTC
yes it is
esp that what required does now feels not explicit enough
Tim Cooper
@coop
Apr 02 2016 11:57 UTC
I agree.
Piotr Solnica
@solnic
Apr 02 2016 11:58 UTC
it needs to work with a type check, I wonder if we could get rid of that
so required(:int?) or required(:array?) etc
and I wonder if we could just use a single predicate somehow, otherwise we do filled? & int?
whereas that could just be int?, it would suffice
Tim Cooper
@coop
Apr 02 2016 11:59 UTC
I sort of like the idea that you might do required(:key).value(int?)… but I don’t think it actually solves the problem.
Piotr Solnica
@solnic
Apr 02 2016 12:00 UTC
I had the same idea too actually, still need to think more about this though
Tim Cooper
@coop
Apr 02 2016 12:00 UTC
Maybe value just takes a bunch of predicates?
bbs
Piotr Solnica
@solnic
Apr 02 2016 12:02 UTC
that could work, maybe ;D
value(:str?, :filled?) == required(:str?)
it’s a longer form, but it’s more explicit and actually more flexible
:filled? means a non-empty value, regardless of the type, anything that responds to size and it returns > 0 OR is not nil will be treated as filled
it’s pretty much a predicate designed to be used for Form and JSON types
Tim Cooper
@coop
Apr 02 2016 12:04 UTC
I’m not opposed to a longer form on the value side especially if we don’t know the abstraction at the moment.
Piotr Solnica
@solnic
Apr 02 2016 12:04 UTC
yeah, and value is probably very easy to understand?
Tim Cooper
@coop
Apr 02 2016 12:05 UTC
I believe so.
And it basically reads like english.
Piotr Solnica
@solnic
Apr 02 2016 12:05 UTC
required(:age).value(:int?, gt?: 18)
this reads nice
Tim Cooper
@coop
Apr 02 2016 12:05 UTC
Yep.
Piotr Solnica
@solnic
Apr 02 2016 12:06 UTC
yeah, I start to like this
Tim Cooper
@coop
Apr 02 2016 12:08 UTC
I really like this.
Piotr Solnica
@solnic
Apr 02 2016 12:09 UTC
we could have type-spec macros for this too
ie required(:age).int(gt?: 18)
but I dunno :)
Tim Cooper
@coop
Apr 02 2016 12:09 UTC
I think you could cut a release that doesn’t introduce any other macros other than value.
See what the use cases are.
Piotr Solnica
@solnic
Apr 02 2016 12:10 UTC
yep
Tim Riley
@timriley
Apr 02 2016 12:21 UTC
This sounds good to me.
Piotr Solnica
@solnic
Apr 02 2016 12:21 UTC
ah, I completely forgot about the original problem
which is how to rename required
value(:filled?) would be very common, we want that to be collapsed to a macro
and the big question was, how to name it
since we want required on the left…then we can’t have it on the right, too
so endash proposed not_nil which is fine, but not in the context of forms (which is super common) because there we want to express that something cannot be empty
Tim Riley
@timriley
Apr 02 2016 12:24 UTC
Could it just be .filled()?
Piotr Solnica
@solnic
Apr 02 2016 12:24 UTC
yes I thought about that
Tim Cooper
@coop
Apr 02 2016 12:40 UTC
filled? is not nil or an empty string right?
Tim Cooper
@coop
Apr 02 2016 12:48 UTC
:filled? means a non-empty value, regardless of the type, anything that responds to size and it returns > 0 OR is not nil will be treated as filled
Tim Cooper
@coop
Apr 02 2016 12:54 UTC
I’m taking a look at the definition of filled? and it doesn’t seem to line up with @solnic’s definition (not the size part - otherwise it is as expected):
      predicate(:filled?) do |input|
        !self[:empty?].(input)
      end

      predicate(:empty?) do |input|
        case input
        when String, Array, Hash then input.empty?
        when nil then true
        else
          false
        end
      end
Piotr Solnica
@solnic
Apr 02 2016 12:56 UTC
@coop ugh. Seems loke
line I forgot my own code theb
Then even
Tim Cooper
@coop
Apr 02 2016 12:56 UTC
I might be out on my own but I kind of like present? over filled? (empty and present also seem to mirror each other better too).
Piotr Solnica
@solnic
Apr 02 2016 12:57 UTC
Really? I hate present. Because nil is present too.
Tim Cooper
@coop
Apr 02 2016 12:58 UTC
I was tossing that around in my head tbh, you’d have to have rules about nil, IMO nil is not present. I’ll look what rails does (not that it is something you’d want to mirror, just for information).
irb(main):001:0> ''.present?
=> false
irb(main):002:0> nil.present?
=> false
Piotr Solnica
@solnic
Apr 02 2016 12:59 UTC
The value is not present when there is no key
Tim Cooper
@coop
Apr 02 2016 12:59 UTC
That is what I expected.
Piotr Solnica
@solnic
Apr 02 2016 13:00 UTC
I deliberately did not follow this logic tbh
It is the source of confusion for me
Tim Cooper
@coop
Apr 02 2016 13:00 UTC

I deliberately did not follow this logic tbh

I figured as much.

I think filled? can work.
Piotr Solnica
@solnic
Apr 02 2016 13:01 UTC
Filled means the value exists and is not empty
If the key is missing then there is no value
Tim Cooper
@coop
Apr 02 2016 13:01 UTC
I can get behind that.
Piotr Solnica
@solnic
Apr 02 2016 13:02 UTC
And we do not apply any rules to the value because it is not there. Despite ruby happily returning nil on non-existant key access
It is a feature of dry-v :)
Tim Cooper
@coop
Apr 02 2016 13:02 UTC
Your defintiion of filled is how I think of the word “present”. If you were to use the word present you would have to train people on what it means in dry-v vs rails.
Piotr Solnica
@solnic
Apr 02 2016 13:02 UTC
(naming aside)
Yeah man hence it is not called present
Tim Cooper
@coop
Apr 02 2016 13:03 UTC
As I said, I can get behind filled?.
:)
Piotr Solnica
@solnic
Apr 02 2016 13:03 UTC
Cool. It was discussed with others in the super early days (FWIW)
Gotta run...ttyl and thanks for discussion
Tim Cooper
@coop
Apr 02 2016 13:04 UTC
no problems.
Fran Worley
@fran-worley
Apr 02 2016 17:10 UTC
@solnic one thing I'm not clear on with the value syntax is how it would work with conditionals and or's. Would you end up with something like: required(:key).value(:filled?).or(:empty)
Piotr Solnica
@solnic
Apr 02 2016 17:16 UTC
@fran-worley for ORs you can use blocks
filled? | empty?
If it can be nil just use maybe
Fran Worley
@fran-worley
Apr 02 2016 17:17 UTC
Thanks @solnic new query on the #90. If you go to the lengths of adding a value method for clarity, is it right to remove the key method in favour of required vs optional?
Piotr Solnica
@solnic
Apr 02 2016 17:37 UTC
I thin required is more explicit than key
Think even
Fran Worley
@fran-worley
Apr 02 2016 17:39 UTC
I guess it better explains the fact it will
Returns as an error when they key is missing
John Backus
@backus
Apr 02 2016 22:20 UTC
@solnic I have some free time today and I'd be interested in filling out some unit tests for part of dry-types. Would you be interested in a PR which just improves coverage?
Piotr Solnica
@solnic
Apr 02 2016 22:21 UTC
@backus which parts?
John Backus
@backus
Apr 02 2016 22:22 UTC
I would be interested in adding coverage to Dry::Types::Struct
but I am happy to help with other parts
I just want to learn the codebase better and help out since I learn from doing so and it will also hopefully improve a project which I am likely to depend on in other codebases
John Backus
@backus
Apr 02 2016 22:29 UTC
Build is green on #63 also dry-rb/dry-types#63
Not sure if my fix could be implemented better but it adds tests for and addresses the issue
Piotr Solnica
@solnic
Apr 02 2016 22:37 UTC
@backus thanks for helping out!
John Backus
@backus
Apr 02 2016 22:38 UTC
Happy to :)
(Can I take that as a "go ahead" @solnic?)
:) fast merge
Piotr Solnica
@solnic
Apr 02 2016 22:43 UTC
@backus I gave you commit access. Feel free to push test cov improvements. If you are not certain about sth just send a PR
John Backus
@backus
Apr 02 2016 22:44 UTC
Oh wow awesome
Thanks!