Hacker News Reader

Comment by nurettin | Hacker News Reader

does that mean you went from

    def send_alerts():
      for person in everyone:
        Mail.send(type="alert", person)

where Mail.send calls an object that was created with Mail.create(env=os.environ["ENV"])

    def send_alerts(mail: Mail):
      for person in everyone:
        mail.send(type="alert", person)

where send_alerts is called as

    send_alerts(Mail.create(env=os.environ["ENV"]))

?

View on HN

Not the OP, but yes I imagine that's what they did. But Mail would probably be created further up (probably at the top level in the main function), and passed to send_alerts, rather than created inline.

I use this approach in all my Haskell/Scala code, and it works really nicely. I have never once felt the need for some magicy DI framework. I just pass the dependencies via function arguments. If it becomes too bloated, I group dependencies, or rethink my design.

Doesn't that mean you need to bubble up every dependency up the stack? Like if function a calls b which calls c which calls d, and d needs a new dependency, wouldn't that involve modifying a, b, and c's function signatures and all call sites?

Yep it does require a little more work when bubbling dependencies. However it's less of a hassle that it might seem since changing dependencies is less common than I initially antecipated.

group dependencies as in

    def send_alerts(services):
      for person in everyone:
        services.mail.send(type="alert", person)


?

That is one option, yeah. I wouldn't do it in this example though. I'd keep it as Mail.

Reply on news.ycombinator.com