On: You have ruined JavaScript

[tomp]

> it's how you pass them around and use them in a component that has no knowledge of the outside world

You pass it as a function argument.

    function needs_to_make_a_car(car_maker, road) {
      var car = car_maker()
      car.drive_on(road)
    }

To which you would probably reply: "But that's exactly what FactoryFactory/DependencyInjection/... pattern is!"

To which we would reply: "Exactly, which are just fancy words for the re-and-re-discovered concept of functional programming."

[haberman → tomp]

> To which you would probably reply: "But that's exactly what FactoryFactory/DependencyInjection/... pattern is!"

Actually no. DI does a lot that your simple examples do not. Notably, it understands the graph of dependencies between decoupled compoments and constructs provided values in the correct order.

[adamtj → haberman]

DI is a design pattern. A design pattern is a conventional way to structure code to solve a particular type of problem. A way to structure code is not a thing that can analyze graphs.

Maybe you're talking about some particular DI framework. That would be a library with functions and classes to make implementing the DI pattern easier. There are many such frameworks, and some of those frameworks may well do automatic graph analysis. But, graph analysis is not inherent in the pattern.

Your specific framework is not the general pattern.

[Glide → tomp]

Except you don't touch on other aspects of what makes IoC containers useful in the real world.

I've seen XML configurability used as an extension point for code that would otherwise be closed. I've seen bugs happen because the lifecycle of objects have been mismanaged. You're conflating that things can be done more elegantly using functional programming to think it belongs in a functional paradigm.

IoC containers in .NET are easier to use and more elegant because of functional programming constructs, but their existence doesn't remove the need to have them.

[outworlder → Glide]

> I've seen XML configurability used as an extension point for code that would otherwise be closed.

Take a step back, and think why that 'extension point' had to be closed to begin with. You're probably going to find either an architectural flaw, or a problem with your tooling that should not have required this sort of thing in the first place.

Also disturbing is that you are using XML to add a degree of expressiveness missing from whatever tooling you are using.

[Glide → outworlder]

Hmm. So small example on what I saw recently was being able to swap the authorization/authentication piece from hitting a service to users defined in XML for locally running the project. Architecture flaw? No. Problem in tooling? If you have a convincing enough argument, yeah. Does Spring feel like it lets you do too much in XML? Hell yes. It's awesome when it works. It feels too convoluted when you don't need it.

[zoomerang → tomp]

> functional programming.

That's not functional programming.