1. 8

  2. 3

    Complicated IoC machinery in a language where you could simply monkey-patch in a suitable mock for testing purposes, instead, seems….misguided.

    1. 6

      From experience, I’ve found that a “monkey-patching is OK” attitude makes it more likely that code ends up being tightly coupled, tangled and hard to build upon or refactor over time. The use of a container here is pretty lightweight, and would bring real benefits when used in a real app worked on consistently across months or years. Granted, as the author of this article, I’m still showing relatively small examples. I hope to build up to bigger things over time!

    2. 3

      I’ve looked into the whole dry-rb stack a few times, and each time I came away confused. To me it feels like trying to force ruby to be something that it’s really not. Why try to bolt on a type system and stuff from functional languages, when there are perfectly good languages that come with those features baked right in?

      I mean, I appreciate all the hard work that’s gone into it, I just don’t really understand the “why”.

      1. 1

        I don’t think the goal is to apply stronger typing to the language as a whole, just to the places in apps where it really helps, like ensuring data is properly validated, entity objects are instantiated with valid state, etc. This makes things easier to work with because you can be much more confident about the shape of your data.

      2. 2

        It’s not entirely clear to me how you would inject an alternate collaborator, as one may want to do in tests. You could use the generated initializer, I’m sure, but then you need to know the order of arguments and supply all of the collaborators? Or do you make special one-off containers that wire up the stubs?

        I confess to not having read the documentation for those kind yet, but It would be nice information to have in a follow up blog post.

        Also… not convinced this is a great idea in Ruby, but I like seeing different approaches.

        1. 2

          dry-auto_inject also supports initializers with hash arguments and Ruby 2.0 keyword arguments, so that would make injecting alternative dependencies in tests more straightforward. dry-container also has a test mode that allows you to stub specific registrations, so you have a couple of options there.

          This is certainly a different approach to Ruby than the norm, but as someone who has been plugging away at Rails apps for a decade, this feels so much nicer. Thanks for the follow-up ideas. I’ve put them in the list! There’s still plenty to talk about, but I’ll get there :)