pago / pioc Goto Github PK

Lazy injection would help with circular dependency resolution and should probably be supported by pioc.

Lazily injecting properties should be simple by adding another annotation:

var pioc = require('pioc');
exports = module.exports = function() { /* ... */ };
exports.sayHello = function() {
  this.log('Hello World');
};
exports.log = pioc.lazyInject('log');

The log dependency would be resolved as soon as this.log is accessed. We can do that by using EcmaScript 5 getter properties. However, it would be necessary to detect or prohibit access to the lazily injected property during the construction of the object, otherwise, we'd still have a circular dependency issue.

With that in mind, supporting lazy constructor injection should not be a goal (though I'm open for suggestions on how to achieve that).

I'm trying to understand why the following situation does not works. Can you help me?

Example 1:

 var module = pioc.createModule()
    .bind('services/consoleService', require('./services/consoleService.js'))
    .bind('services/dummyService', require('./services/dummyService.js'))
...
injector.resolve(function (services) {
      console.log(util.inspect(services)); // Array[2] - Expected
});

injector.resolve(function (consoleService) {
      console.log(util.inspect(consoleService)); // Array[0] - Should not return the consoleService?
});

Example 2:

 var module = pioc.createModule()
    .bind('services_consoleService', require('./services/consoleService.js'))
    .bind('services_dummyService', require('./services/dummyService.js'))
...
injector.resolve(function (services) {
      console.log(util.inspect(services)); // Array[2] - Expected
});

injector.resolve(function (services_consoleService) {
      console.log(util.inspect(services_consoleService)); // Object - It works but it's not pretty
});

Thank you!

https://github.com/jaredhanson/electrolyte is also a dependency injection container and utilizes a slightly different syntax to define module dependencies. It is also much more established.

Supporting a @require property on service functions should be relatively easy and would allow compatibility with electrolyte modules.

The more complicated part is the @singleton property. Since pioc tries to be smart about when to instantiate a dependency, most things are singletons by default (unless registered with Module.bindFactory). We could assume a different behaviour with regards to @singleton when @require is present but that'd limit the addition of support for @require to be purely for compatibility instead of it being a valid alternative for module dependency definition.

pioc should definitly try to be as compatible with other DICs as much as possible - at least with regards to how modules can be defined.