These are chat archives for dry-rb/chat

17th
Mar 2016
Adam Davies
@adz
Mar 17 2016 01:09
Congrats on Dry-* release! Nice work
… i’ve been doing a lot of front end work lately, so haven’t followed what’s been going on. On that note, a meet up on purescript (with remote access) might be interesting to some of you here… (happening in around 20m)
http://www.meetup.com/Bay-Area-PureScript-Meetup/events/229075997/
Adam Davies
@adz
Mar 17 2016 01:47
damn no wifi, they can’t stream… oh well
Piotr Solnica
@solnic
Mar 17 2016 11:00
@adz technology eh?
Michał Pietrus
@blelump
Mar 17 2016 11:29
cześć @solnic :-) , would you have a while today to speak about that comment regarding reform and dry-v ?
Piotr Solnica
@solnic
Mar 17 2016 11:34
@blelump heja. Hopefuly yes
Michał Pietrus
@blelump
Mar 17 2016 11:41
sure :fire:
Ralf Schmitz Bongiolo
@mrbongiolo
Mar 17 2016 13:13
@blelump I added my point to the discussion there, right now I think it's hard to fully integrate dry-v with reform, some key underlying key concepts seems divergent. The validation side of dry-v could still be used without a problem I think, but reform would still do everything else.
And as I put in the end of my comment, maybe we just need a forked reform that rework the internals to better integrate some of the dry-rb gems. As right now dry-types and dry-validation overlap with reform on what they can do.
Michał Pietrus
@blelump
Mar 17 2016 13:17
@mrbongiolo , maybe PM to not troll the channel with Reform stuff? :-)
Ralf Schmitz Bongiolo
@mrbongiolo
Mar 17 2016 13:22
@blelump true
Andy Holland
@AMHOL
Mar 17 2016 13:25
@blelump @mrbongiolo Post it here, it's still relevant and interesting to read, could you link to the discussion you mentioned please?
Ralf Schmitz Bongiolo
@mrbongiolo
Mar 17 2016 13:25
@AMHOL apotonick/reform#347
Andy Holland
@AMHOL
Mar 17 2016 13:25
TY :)
Michał Pietrus
@blelump
Mar 17 2016 13:25
:-)
Andy Holland
@AMHOL
Mar 17 2016 13:48
@blelump Pretty sure dry-validation has an #attr predicate which is synonymous to #key but used for method access rather than #[] access, if that's what you meant in the issue above?
Michał Pietrus
@blelump
Mar 17 2016 13:48
@AMHOL , could you point which comment?
Also, most persistence libraries implement #[] for property access
Michał Pietrus
@blelump
Mar 17 2016 13:51
well, I'm pretty sure I wasn't speaking about attr. What sentence do you mean ? :-)
Andy Holland
@AMHOL
Mar 17 2016 13:58
Caveat: @solnic , would it be possible that dry-v eats object and checks rules against object instead of a hash? In such case, I would be able to pass e.g an OpenStruct object, e.g. schema.(OpenStruct.new({name: 1})). That would significantly simplify Reform validation process. It would even handle coercions inferring and that would be a blast :smile: . What do you think? Is object state mutation not too much here?
Sorry, should've made that clear
Michał Pietrus
@blelump
Mar 17 2016 14:00
sure let me clarify
Piotr Solnica
@solnic
Mar 17 2016 14:01
it’s gonna work if the input object responds to #[]
for value access through attr readers, use attr instead of key
https://github.com/apotonick/reform/pull/347#issuecomment-197891086 more about dry-v + reform /cc @blelump @mrbongiolo
Michał Pietrus
@blelump
Mar 17 2016 14:02
yup, got a mail :-)
here’s a schema for a “model” rather than a hash
this feature is not documented because I don’t like it and I don’t use it. I need to ask for help with documenting it
Michał Pietrus
@blelump
Mar 17 2016 14:03
brb
Ralf Schmitz Bongiolo
@mrbongiolo
Mar 17 2016 14:05
but then the reform end-user would have to use attr instead of key right?
Piotr Solnica
@solnic
Mar 17 2016 14:05
I don’t know what is being passed in to schema’s call method
if it’s an object graph built by reform, then attr is probably better, but I wouldn’t like it
Ralf Schmitz Bongiolo
@mrbongiolo
Mar 17 2016 14:06
right now it's the Hash
Piotr Solnica
@solnic
Mar 17 2016 14:06
see my recent comment in the PR for more insight
Ralf Schmitz Bongiolo
@mrbongiolo
Mar 17 2016 14:06
Yeah I read it, and I agree with it
Piotr Solnica
@solnic
Mar 17 2016 14:06
can you react to it? it excites me when people react to things on github ;) :joy:
Ralf Schmitz Bongiolo
@mrbongiolo
Mar 17 2016 14:06
but @apotonick seems to have another opinion on that for Reform
@solnic there you go o/
Piotr Solnica
@solnic
Mar 17 2016 14:07
hahah :)
such reactions, you’re the best
@mrbongiolo I’ll try to convince @apotonick that current approach is OKish but it’s wrong and we could do better w/o loosing main features of reform
it’s wrong in principle, but it’s OKish because it’s useful and probably “handy"
Ralf Schmitz Bongiolo
@mrbongiolo
Mar 17 2016 14:09
Sure, I agree
Piotr Solnica
@solnic
Mar 17 2016 14:09
my theory is that you can maintain the usefulness of property DSL and related features while using dry-v in a better way
this includes potentially simplifying reform
but I really need to understand reform better, I’ve never used it. I was only looking at source code :)
Michał Pietrus
@blelump
Mar 17 2016 14:11
OK, I'm on
let me clarify my point of view
Ralf Schmitz Bongiolo
@mrbongiolo
Mar 17 2016 14:14
And reform itself is a bit old, it comes with another "vision" of how things worked, you basically just had rails and am:v
Piotr Solnica
@solnic
Mar 17 2016 14:18
I know, it brings legacy with it, just like virtus
Ralf Schmitz Bongiolo
@mrbongiolo
Mar 17 2016 14:18
Uhum
Piotr Solnica
@solnic
Mar 17 2016 14:19
would be really awesome to see if things could be improved and simplified while main features stay the same
from the usage pov
as I said, my theory is that it’s doable :)
Michał Pietrus
@blelump
Mar 17 2016 14:19

I believe the way dry-v should be used is shown best in formalist, where data validation appears first and then, upon the result and form "schema", the AST is being built. The same I think about Reform. However, Reform is built with a concept of twins, where each twin object is just a twin of the real model in AR and essentially, any thing you may want to perform before persistence state, is going to be performed on twin, not the real model. Validation process is also fired against twins

I asked about validating objects and what @AMHOL tried to clarify to me, because Reform validates objects. However it's possible to serialize it to hash with primitives, I feel this is not right since there're already built object graph (twins)

Piotr Solnica
@solnic
Mar 17 2016 14:20
@blelump yep, see my comment in PR. I think schema should be applied before building object graph using twins
simply because a twin can crash if data is not valid
Ralf Schmitz Bongiolo
@mrbongiolo
Mar 17 2016 14:21
But as you said in your comment, you might end up with double definitions, for twin properties and the schema
Piotr Solnica
@solnic
Mar 17 2016 14:22
if the current approach stays the same, then yes, there will be no way around that
I mean…you could only specify validation rules, and skip the 100% schema definition, and that would still work, this would reduce boilerplate
Ralf Schmitz Bongiolo
@mrbongiolo
Mar 17 2016 14:23
so we have to wait on what @apotonick thinks about it
Piotr Solnica
@solnic
Mar 17 2016 14:23
by default input processor in a schema is a noop, so it’s gonna pass through whole hash
yeah totally, this needs discussions and careful considerations
Michał Pietrus
@blelump
Mar 17 2016 14:23
@solnic , but it's like using a demo version of some app
I mean, you have features, but you cannot use them
Piotr Solnica
@solnic
Mar 17 2016 14:24
I agree, reform would leverage a subset of what dry-v provides
STILL better than AM though
Michał Pietrus
@blelump
Mar 17 2016 14:24
I see
Piotr Solnica
@solnic
Mar 17 2016 14:24
:trollface:
Michał Pietrus
@blelump
Mar 17 2016 14:26
trying to wake up @apotonick
Piotr Solnica
@solnic
Mar 17 2016 14:27
1:30am over there :)
Michał Pietrus
@blelump
Mar 17 2016 14:28
uhm, so that's not gonna happen ;-)
Piotr Solnica
@solnic
Mar 17 2016 14:33
http://metaruby.com/t/dry-rb/469 /cc @AMHOL @timriley
would be good to mention how dry-container differs from heavy IoC in Java or C#
I mean in docs, I’m sure lots of people will have that concern
Andy Holland
@AMHOL
Mar 17 2016 14:40
#noXML
:trollface:
Piotr Solnica
@solnic
Mar 17 2016 15:33
@AMHOL not sure if “a simple validation library” is still a good description ha-ha
Andy Holland
@AMHOL
Mar 17 2016 15:34
:laughing:
"a decent validation library"
Michał Pietrus
@blelump
Mar 17 2016 15:37
not sure what makes a library complex or simple , but the AST concept behind it is definitely 'not simple' ;-)
Piotr Solnica
@solnic
Mar 17 2016 15:41
@blelump ast processing is complicated because we support both nested schemas and nested keys. It’s VERY likely I’ll remove nesting keys and only nested schemas will be supported
I already changed all docs to always show nested schemas rather than keys
Michał Pietrus
@blelump
Mar 17 2016 15:51
so I suppose, nesting a key is additional garbage to the AST, whereas nested schema is just another AST , am I right ?
Piotr Solnica
@solnic
Mar 17 2016 15:54
@blelump yes, it’s very complex because there’s no formal way of specifying that something is a nested hash from dry-logic rule ast pov
and adding this concept to dry-logic would complicate it, so it makes no sense
actually, I think it’s safe to say that nested keys will be removed, I’m 99.9% certain about that
Michał Pietrus
@blelump
Mar 17 2016 16:01
:+1: