[michaelw]

While I agree with what SICP says, the function in this case isn't really a function. It's not something a caller will ever invoke explicitly. It exists to provide a closure that can be initialized with the injected parameters.

Pretend for a moment that Javascript had macros (sweet.js where are you?) and the Angular syntax was more explicit:

  myModule.provider ProviderName
  inject $scope, $document, SomeOtherDependency
  {
    your code here
  }

The last thing you'd expect is a syntax where the injected dependency names were chosen by the implementor of the provider.

Javascript's greatest weakness is that it's native syntax is poorly suited for creating language like extensions. The result is that things like modules, imports, etc. tend to be very verbose and noisy.

[davexunit]

>Pretend for a moment that Javascript had macros (sweet.js where are you?) and the Angular syntax was more explicit:

Well, sure. If and when JavaScript gains hygienic macros (via sweet.js or otherwise), I will like this sort of notation. However, the reality is that JavaScript doesn't have macros currently. Thus, I still dislike the magical dependency notation.

>The last thing you'd expect is a syntax where the injected dependency names were chosen by the implementor of the provider.

I don't see why this is bad. Several languages allow you to rename things in imported modules. The two that I can think of immediately are Python and Guile Scheme. Most of the time there is no reason to rename, but sometimes it is a good idea to rename for clarity or to avoid name clashes. This is something that you can already do via the explicit form of dependency injection.

[andreypopp]

Here you go — http://bit.ly/1ic1X49