Feature request: native language support for dependency injection.

[DartBot]

This issue was originally filed by michaels...@gmail.com

---

Guice and other dependency injection solutions used in Java involve quite a lot of magic and special annotation classes to work. It would be really nice if there were native language support for DI which could simplify and eliminate a lot of the apparent magic and syntactic verbiage involved in such schemes.

[DartBot]

This comment was originally written by jat@google.com

---

Factories already go a long way towards a better way to do dependency injection, but definitely we want to have good support for the ideas of dependency injection, though not current implementations.

---

Removed Type-Defect label.
Added Type-Enhancement, Area-Library, Triaged labels.

[DartBot]

This comment was originally written by ma...@gmail.com

---

Actually, Factories and Inversion-Of-Control are enemies. IOC is trying to solve the reusable modularity / plugability of software.. Something constructors do HORRIBLY - as they produce direct coupling of class-specialization - meaning they throw away any polymorphism at the point of the call-to-new; might as well have been all static c-type-functions.

That being said, and with my shared excitement of the possibility of crafting something new and innovative at the language-level that leverages my passion for IOC, from what I've read from other issue-tickets, there is an active avoidance in the dart-management to creating high-surprise-factors. I guess I'm looking at lua's success as an embedded language; mainly it's insane simplicity (not that I like it, but that must have helped it proliferate).

[DartBot]

This comment was originally written by marai...@gmail.com

---

Oh, for completeness.. Technically Factories that leverage singletons that are initialized by some global startup CAN facilitate dependency-injection (and technically that's what guice/spring do in java when you boil it all down), BUT this only works/makes-sense if there is a central-configuration-authority that makes this decision. e.g. a single global/singleton/factory. If you have 500 factories that each make explicit calls to other global factories, then all you've done is created 500 global variables.. And I hope I shouldn't need to remind people what 1980's global-variable-fest turned into.

I only make this clearification because I've seen too many programmers go "yeah, we'll just use the factory pattern; problem solved" and I bang my head on the desk when it comes time to unit-testing and find nested layers of factories that are nearly impossible to mock.

[DartBot]

This comment was originally written by marai...@gmail.com

---

And just to get it off my chest (because as in comment 2, I understand that the answer is ultimately that this should be handled at a higher level than the core-language)..

Dart CAN support spring-style dependency-injection through:

class BeanFactory {
  BeanFactory parent;

  Map<String,Object> _name2Instance;
  Map<String,Function> _name2PrototypeFactory;
  
  BeanFactory([this.parent]): _name2Instance = new Map<String,Object>()
               , _name2PrototypeFactory = new Map<String,Function>()
  {}

  // Get a singleton (or null)
  getBean(String name) {
      var res = _name2Instance[name];
      return res != null || parent == null ? res : parent.getBean(name);
  }

  // assume we're storing a factory closure instead of the object itself
  // note the null-safe pseudo-code (in other issue-tickets)
  createPrototype(String name) {
    var res = _name2PrototypeFactoryname;
    return res != null || parent == null ? res : parent.createPrototype(name);
  }

  // void-main or Init methods populate this with instances and factories
  registerBean(String name, Object obj) => _name2Instance[name] = obj;

  registerPrototype(String name, Function factory) => _name2PrototypeFactory[name] = factory;

}

void main() {
   BeanFactory bf = new BeanFactory();
   bf.registerBean("abc", "hi");
   int i = 5;
   bf.registerPrototype("def", () => "zip" + (++i));
   var o1 = bf.getBean("abc");
   var o2 = bf.createPrototype("def");
   var o3 = bf.createPrototype("def");
   print("o1=${o1}\n");
   print("o2=${o2}\n");
   print("o3=${o3}\n");
}

If this were a core library, then it would highly encourage it's adoption by 3rd party library writers.

Separately, as a convention, you could encourage such bean-factory-safe configurations such as:

class Foo {
  var _dao, _lockManager;
  Foo() { }
  Foo.beanFactory(this._dao, this._lockManager) { }
  ...
}

Now to allow dynamic/reflective construction, we'd need dart to centrally store metadata about the compilation unit.. Namely either or both of constructor.factory parameter names.

Ideally you could go all the way to the types.. That would, of course, require the ability to do all sorts of java style Class and Method operations as well.

[DartBot]

This comment was originally written by mar...@gmail.com

---

Ok, NOW that I've learned about dart factories, I understand what you meant jat.. It took me about 15 hours of incremental "wtf is this" before I finally distilled my thoughts in a blog-post:

https://plus.google.com/u/0/110377859584351043951/posts/1FsB87X3fFp

I still advocate some sort of standardized way of scoping all the singletons, but I think I agree that the core might not be the best place to enforce it. It also feels humbling without some sort of reflective capability.