5 ms·

I'm curious what you think the fundamental difference is between passing configuration through functions and closures, and passing it with classes. Classes are

I'm curious what you think the fundamental difference is between passing configuration through functions and closures, and passing it with classes. Classes are just fancy closures, after all.

rraghur 6y ago
Discussion a couple of days around .Net 5 release announcement ended up going into di vs no di.. I'm on mobile but you can get to it from my comment history
rraghur 6y ago
More ceremony & semantic load of course and you end up with having to define single use abstractions so that you can mock them in tests I've long been in the pro DI camp and used to think that interfaces and brittle tests were unavoidable.. Only after i recently got into FP with f#, I've come to appreciate how i used to conflate good IoC design with DI usage.. I'm pretty sure that I'm not alone
- jolux 6y ago
  If you find yourself creating a lot of single-use abstractions, I think you're probably doing something wrong. In particular a lot of containers (I know Autofac) support Func<> very well. As for ceremony and semantic load, I can't argue here, though I think following DI restricts some of the semantic load that comes with abstracting mainly through inheritance and through managing stateful dependencies.
brundolf 6y ago
I look at classes as holders of mutable state. While a closure can technically hold mutable state, subjectively I feel there's a convention that closure captures are often treated as constant (mainly by association with the functional paradigm).
- sk5t 6y ago
  One doesn't need to think of classes that way, though. A class could hold immutable references to immutable objects/functions/whatever (these are often the easiest classes of all to reason about). Call me a weirdo, but I enjoy using Spring DI with Scala. It's quite easy to inject into a constructor like "class Foo(f: Int => String)" even if a little bit of "manual currying" is sometimes needed.
  - brundolf 6y ago
    Spring DI implies automatic DI containers, right? So how would that work with an abstract function type (as opposed to a specific class that gets instantiated)?
    - sk5t 6y ago
      I actually like fairly explicit XML-based config with Spring. Something like "<constructor-arg value='#{thing.fnFor("x")}'/>" for example. Connects the pieces without relying on inference/magic.

I'm curious what you think the fundamental difference is between passing configuration through functions and closures, and passing it with classes. Classes are just fancy closures, after all.

rraghur 6y ago

Discussion a couple of days around .Net 5 release announcement ended up going into di vs no di.. I'm on mobile but you can get to it from my comment history

rraghur 6y ago

More ceremony & semantic load of course and you end up with having to define single use abstractions so that you can mock them in tests I've long been in the pro DI camp and used to think that interfaces and brittle tests were unavoidable.. Only after i recently got into FP with f#, I've come to appreciate how i used to conflate good IoC design with DI usage.. I'm pretty sure that I'm not alone

jolux 6y ago
If you find yourself creating a lot of single-use abstractions, I think you're probably doing something wrong. In particular a lot of containers (I know Autofac) support Func<> very well. As for ceremony and semantic load, I can't argue here, though I think following DI restricts some of the semantic load that comes with abstracting mainly through inheritance and through managing stateful dependencies.

brundolf 6y ago

I look at classes as holders of mutable state. While a closure can technically hold mutable state, subjectively I feel there's a convention that closure captures are often treated as constant (mainly by association with the functional paradigm).

sk5t 6y ago
One doesn't need to think of classes that way, though. A class could hold immutable references to immutable objects/functions/whatever (these are often the easiest classes of all to reason about). Call me a weirdo, but I enjoy using Spring DI with Scala. It's quite easy to inject into a constructor like "class Foo(f: Int => String)" even if a little bit of "manual currying" is sometimes needed.
- brundolf 6y ago
  Spring DI implies automatic DI containers, right? So how would that work with an abstract function type (as opposed to a specific class that gets instantiated)?
  - sk5t 6y ago
    I actually like fairly explicit XML-based config with Spring. Something like "<constructor-arg value='#{thing.fnFor("x")}'/>" for example. Connects the pieces without relying on inference/magic.