Skip to content
This repository was archived by the owner on Dec 6, 2017. It is now read-only.

Conversation

antingshen
Copy link
Contributor

No description provided.

Anting Shen and others added 9 commits June 25, 2014 16:14
BREAKING CHANGE
- Calls to StaticInjector and DynamicInjector should be replaced with ModuleInjector
  - There are no longer StaticInjectors and DynamicInjectors. They have been replaced
    by a new ModuleInjector class that acts as both types of injectors. There is also
    a faster NodeInjector class for specific use cases where many injector features
    aren’t needed. (Miško has more info on NodeInjectors)

- ModuleInjectors have no visibility
  - All bindings and instances of parent injectors are now visible in child injectors.
    NodeInjectors do, however, have some sense of visibility.
  - The optional argument “forceNewInstances” of Injector.createChild has been removed
    Instead, create a new module with bindings of the types that require new instances
    and pass that to the child injector, and the child injector will create new
    instances instead of returning the instance of the parent injector.

- Use “new ModuleInjector(modules, parent)” instead of “Injector.createChild(modules)”
  - The latter is still available but deprecated.
  - Injectors with no parent now have a dummy RootInjector instance as the parent
    Instead of checking “parent == null”, check for “parent == rootInjector”.

- Injectors no longer have a name field

- typeFactories have changed
  - Old type factories had the form (injector) => new Instance(injector.get(dep1), … )
  - New factories have one of:
    - toFactory(a0, a1) => new Instance(a0, a1)
    - toFactoryPos: the form (List<dependency instances> p) => new Instance(p[0], p[1] ..)
  - When calling Module.bind(toFactory: factory), there is an additional argument “inject”
    of a list of types or keys (preferred for performance) whose instances should be
    passed to the factory. The array “p” passed to the factory function will be instances
    of the types in “inject”.

    Example:
    - Old code. module.bind(Car, toFactory: (i) => new Car(i.get(Engine)));
    - New code.
      - module.bind(Car, toFactoryPos: (p) => new Car(p[0]), inject: [Engine]);
      - module.bind(Car, toFactory: (engine) => new Car(engine), inject: [Engine]);

    There is also some syntactic sugar for this special case.
    - Old code. module.bind(Engine, toFactory: (i) => i.get(Engine));
    - New code. module.bind(Engine, toFactory: (e) => e, inject: [Engine]);
    - With sugar. module.bind(Engine, inject: [Engine]);

- Modules have a TypeReflector instance attached
  - The TypeReflector is how the module will find the “toFactoryPos” and “inject”
    arguments when not explicitly specified. This is either done with mirroring or code
    generation via transformers. Typical use will not need to worry about this at all, and
    the default reflector will suffice. If needed, implement TypeReflector and use
    new Module.withReflector(reflector).
  - Modules need a TypeReflector instance initialized

    import 'package:di/di_dynamic.dart';
    main() {
      setupModuleTypeReflector();
    }

- The transformer has been updated
  - Running the transformer will do the necessary code generation and edits to switch the
    default TypeReflector from mirroring to static factories. Enable transformer to use
    static factories, disable to use mirrors. More docs on the transformer can be found in
    transformer.dart

- Annotating types for injection has not changed.

- And it’s lots faster!
  - Which makes all these changes worth it :)
@antingshen antingshen changed the title fix(benchmarks): Made benchmarks work with new API 2.0.0 code cleanup Jul 15, 2014
@antingshen antingshen mentioned this pull request Jul 15, 2014
@vicb
Copy link
Contributor

vicb commented Jul 16, 2014

The commit message for the 2nd commit need to be updated

Conflicts:
    lib/generator.dart

@antingshen antingshen mentioned this pull request Jul 16, 2014
@jbdeboer
Copy link
Contributor

Landed in v2 as 67b012f

@jbdeboer jbdeboer closed this Jul 16, 2014
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants