I'm doing test-first development, trying to figure out
how hierarchical injectors will work.

The current (dhalem) implementation of hierarchical
injectors does something reasonable with just-in-time
bindings -- each injector gets its own map. And they're
allowed to overlap with their parents.

This might be fine for unscoped bindings but it'll bring
a world of hurt for scoped ones. For example, what
should happen for this test?

  public void testJitBindings() {
    Injector parent = Guice.createInjector();
    Injector child = Guice.createInjector(parent, new AbstractModule()
{
      protected void configure() {
        bind(A.class).toInstance(new A("from-module"));
      }
    });

    B fromParent = parent.getInstance(B.class);
    assertEquals("just-in-time", fromParent.a.value);

    B fromChild = child.getInstance(B.class);
    assertEquals("from-module", fromChild.a.value);
  }

  static class B {
    private final A a;

    @Inject B(A a) {
      this.a = a;
    }
  }

  static class A {
    private final String value;

    @Inject
    public A() {
      this("just-in-time");
    }

    A(String value) {
      this.value = value;
    }
  }


My instinct is to be as restrictive as possible...

1. Forbid any binding from occurring twice in an
injector hierarchy. Parent injectors can't have JIT
bindings that their children have explicit bindings
for and vice versa.

2. Child injectors don't have their own JIT bindings.
All JIT bindings live in the root injector.

3. Child injectors can have private singletons, but
they must be bound explicitly.

For #1 to work, the parent would maintain a set[1] of
blacklisted bindings. These are the explicit bindings
of the child injectors, and the parent promises to
never create JIT bindings for 'em.

Got a simpler/better approach? Please let me know.

Cheers,
Jesse

[1] probably something involving weak references,
   so the parent injector can survive its children


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"google-guice-dev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/google-guice-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to