3 ms·

Which, in FP, is all but invisible: the arguments to a function literally are its dependencies. I think OOP has more primitive concepts (and more mutation) tha

by Twisol 6y ago

Which, in FP, is all but invisible: the arguments to a function literally are its dependencies. I think OOP has more primitive concepts (and more mutation) than FP, so dependency injection in OOP also includes object construction and often mocking effectful operations. That's why it gets its own name in OOP, while being more of an ambient idea in FP.

goto11 6y ago
I don't think I agree with that. In scheme you can write (display "hello world") inside a function and this is directed to some globally configured port. If either the port or the display function was passed as a parameter to the function, then it would be dependency injection.
- Twisol 6y ago
  On its face, you're right. You can formalize this approach using dynamically-scoped variables, which is a step on the road toward coeffect systems in typed functional languages. But in a coeffect system, the type of `display` would explicitly call out that its environment must provide the necessary dynamic variables, which brings us back to dependency injection. `display`'s dependencies would be injected via dynamic scope, which you can override in the caller by defining a dynamic binding. As an alternative, I would suggest that `display` is special, and that instead of thinking of passing an extra parameter to `display`, that the module that calls it should instead have `display` itself injected.
  - goto11 6y ago
    Yes that is actually what I meant, I guess I was not being clear. The function calling "display" could have "display" passed as an argument rather than calling it as a globally defined function. Relying on dynamic variables would probably not be considered dependency injection. A major purpose of DI is that dependencies should be declared in the signature, making it explicit which dependencies a unction or object depends on.
    - Twisol 6y ago
      > A major purpose of DI is that dependencies should be declared in the signature Yes, and a coeffect system would cause dependencies on dynamic variables to be declared statically, even if they're provided by "the environment" at runtime. Tomas Petricek's PhD project page is a good introduction to coeffect systems, and it illustrates dynamic variables as an example. http://tomasp.net/coeffects/ http://tomasp.net/coeffects/

by Twisol 6y ago

goto11 6y ago

I don't think I agree with that. In scheme you can write (display "hello world") inside a function and this is directed to some globally configured port. If either the port or the display function was passed as a parameter to the function, then it would be dependency injection.

Twisol 6y ago
On its face, you're right. You can formalize this approach using dynamically-scoped variables, which is a step on the road toward coeffect systems in typed functional languages. But in a coeffect system, the type of `display` would explicitly call out that its environment must provide the necessary dynamic variables, which brings us back to dependency injection. `display`'s dependencies would be injected via dynamic scope, which you can override in the caller by defining a dynamic binding. As an alternative, I would suggest that `display` is special, and that instead of thinking of passing an extra parameter to `display`, that the module that calls it should instead have `display` itself injected.
- goto11 6y ago
  Yes that is actually what I meant, I guess I was not being clear. The function calling "display" could have "display" passed as an argument rather than calling it as a globally defined function. Relying on dynamic variables would probably not be considered dependency injection. A major purpose of DI is that dependencies should be declared in the signature, making it explicit which dependencies a unction or object depends on.
  - Twisol 6y ago
    > A major purpose of DI is that dependencies should be declared in the signature Yes, and a coeffect system would cause dependencies on dynamic variables to be declared statically, even if they're provided by "the environment" at runtime. Tomas Petricek's PhD project page is a good introduction to coeffect systems, and it illustrates dynamic variables as an example. http://tomasp.net/coeffects/ http://tomasp.net/coeffects/