These are chat archives for dry-rb/chat

2nd
Nov 2016
Nick Sutterer
@apotonick
Nov 02 2016 06:33
hey friends, i have a dry-matcher question
why are all cases always evaluated, even if one matches "above" the other, following?
Tim Riley
@timriley
Nov 02 2016 08:33
@apotonick right now, cases are evaluated in order of their definition, first match wins and subsequent evaluation is halted (I.e. Latter cases not checked)
This is to give the block a meaningful return value
Nick Sutterer
@apotonick
Nov 02 2016 08:48
@timriley not true in my case
@timriley ah, you mean the way they're "used", not defined?
also, why's the API so convoluted, couldn't we save the resolve?
apotonick @apotonick is using Dry.RB like a boss
Tim Riley
@timriley
Nov 02 2016 08:57
What API is convoluted?
Can you let me know what you'd like to do and if/how dry-matcher is not allowing you to do it?
Tim Riley
@timriley
Nov 02 2016 09:03
what I was saying before is that if you have m.foo m.bar and m.baz inside your match block (in that order), and both the bar and baz cases will match, then the bar case's block will run and the overall match block will exit after that because a match has been found. m.baz never runs.
m.bar "wins" because it was first.
Nick Sutterer
@apotonick
Nov 02 2016 09:23
so, that's what you mean?
Matcher.(result) do |m|
      m.unauthenticated { |result| controller.head 401 }
      m.not_found       { |result| controller.head 404 }
      m.created         { |result| controller.head 201, "Location: /song/#{result["model"].id}", result["representer.serializer.class"].new(result["model"]).to_json }
      m.success         { |result| controller.head 200 }
    end
is that the "match block"?
Tim Riley
@timriley
Nov 02 2016 09:28
Yes, that's what I mean.
Tim Riley
@timriley
Nov 02 2016 09:41
We need the resolve option when preparing match cases so that we can prepare the value that gets passed to their blocks (like unwrapping a monad, for example). This is a low-level API, flexibility is useful.
Nick Sutterer
@apotonick
Nov 02 2016 09:47
@timriley agreed, i said convoluted as in "nick doesn't get it"
Nick Sutterer
@apotonick
Nov 02 2016 09:57
@timriley are you thinking about a higher-level api for matcher, or is that up to the user?
AND, way more important: why is it called "pattern matching"? where does the terminology come from (out of curiosity)?
Tim Riley
@timriley
Nov 02 2016 10:44
well, the "end-user” API is pretty high-level/easy-to-use, I think, the Matcher(res) { |m| … } stuff.
As for constructing your own matchers, I think that’s not something you’d do all that often (at most once or twice per app, and even then you could package up your own reusable matcher into a gem if you wanted, like we do with the in-built EitherMatcher), so I’m not sure there’s much need to try and change that API
Pattern matching is actually a functional programming concept: http://wiki.c2.com/?PatternMatching
Tim Riley
@timriley
Nov 02 2016 10:52
Anyway, good to see you playing with this stuff! Keep letting me know how you go, @apotonick :)
Nick Sutterer
@apotonick
Nov 02 2016 10:53
@timriley you will hear the applause with the TRB2 release :P
don't forget to help me with the auto_inject stuff
and thanks for the work you've done! i love integrating it
Tim Riley
@timriley
Nov 02 2016 11:09
Yes, I still hope to do that. I didn't get a chance tonight though. I'm full-time helping with the family now the new baby is here.
Nick Sutterer
@apotonick
Nov 02 2016 11:10
good dad @timriley :highfive:
Piotr Solnica
@solnic
Nov 02 2016 11:37
@flash-gordon sorry about that PR man, I just missed it :(
Nikita Shilnikov
@flash-gordon
Nov 02 2016 11:50
ah, nvm, I should ping you, just forgot completely
Piotr Solnica
@solnic
Nov 02 2016 11:53
@flash-gordon I’d encourage you to push this kind of fixes directly to master
ie I do that, so I don’t see any reason why other devs shouldn't be doing that too
(devs with commit access, of course)
Nikita Shilnikov
@flash-gordon
Nov 02 2016 11:54
kk
Piotr Solnica
@solnic
Nov 02 2016 11:54
I tend to review changes prior releases anyway, and we can always fix/improve things before a release