On: You have ruined JavaScript

[haberman]

Here's a car factory in javascript [...] And here's a configured car factory

Great, now where is the part where the code that provides the "my dealer" string can be completely unaware that makeCar() exists?

Oh, it doesn't exist? That's the problem that Angular DI is solving.

[klmr → haberman]

Here:

    var factory = makeCar;

The whole point of having first-class functions is that you can assign them. The problem a factory solves is precisely the lack of this assignability (which is why a constructor function is wrapped in a class).

[haberman → klmr]

Please put in the effort to understand at least the basic idea of dependency injection before deriding it in favor of "simpler" solutions that do not solve the same problem.

The specific pattern DI can solve here is:

- one module provides some capability by name

- another module makes use of that capability by name

- the two modules have no knowledge of each other, and no higher-level glue code is required to connect them together (and construct the appropriate objects at the right times).

Your "solution" does not satisfy the requirements because it requires you to manually construct the objects in the correct order. DI on the other hand will automatically analyze the graph of dependencies, invoking the appropriate factories in the right order.

[masswerk → haberman]

Sorry to say, but klmr is right. Since functions are first-class objects and references are evaluated late, these issues are already managed by JS and native scopes. There's no need to recreate this functionality in a framework. You might just want to consider the entry point to your code.

[masswerk → masswerk]

P.S.: What this really is about: Unit tests originally designed to go with C/C++ do not work well with late binding. In fact this is a concept totally foreign to these languages. It's essential to understand that these kind of frameworks serve in the first line the purpose of test suites and only in second place the needs of developers. (Developers should not mistake themselves for test suites.)

[zoomerang → klmr]

You're completely missing the point and solving the wrong problem. Function or class, its a minor semantic difference for the same thing.

The issue is not how you define your factories, it's how you pass them around and use them in a component that has no knowledge of the outside world.

[tomp → zoomerang]

> 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.